嗯,看起來我在創建MiniProfilers
table時犯了一個很大的錯誤,因爲我忘記了primary key
被默認聚集......並且聚簇索引是一個GUID列,這是一個非常大的禁忌。
由於數據的物理存儲在磁盤上的相同順序聚集索引(事實上,可以說表是聚集索引),SQL Server必須保持每一個新插入的行中的物理順序。當我們基本上使用一個隨機數時,這將成爲一個噩夢來保持排序。
解決方法是添加自動增加int和切換主鍵的是,就像all the other tables(爲什麼我忽略了這個,我不記得了......我們不棧在這裏使用這個存儲提供商溢出或這個問題很早以前就會發現)。
我將更新表創建腳本,併爲您提供某些內容以便稍微遷移當前表。
編輯
在此再次尋找後,主MiniProfilers
表可能只是一堆,意思是沒有聚集索引。對行的所有訪問權限都是由該列引用的,所以沒有物理排序會有所幫助。
如果你不想重新創建MiniProfiler SQL表,你可以使用這個腳本,使主鍵非聚集:
-- first remove the clustered index from the primary key
declare @clusteredIndex varchar(50);
select @clusteredIndex = name
from sys.indexes
where type_desc = 'CLUSTERED'
and object_name(object_id) = 'MiniProfilers';
exec ('alter table MiniProfilers drop constraint ' + @clusteredIndex);
-- and then make it non-clustered
alter table MiniProfilers add constraint
PK_MiniProfilers primary key nonclustered (Id);
另一個編輯
Alrighty,我已經更新大多數查詢的創建腳本和增加的索引 - see the code here in GitHub。
我會高度建議刪除所有現有表並重新運行更新的腳本。
我可能是錯的,但不會索引減慢插入?或者是否需要索引的後續插入查找?我認爲[this](https://github.com/SamSaffron/MiniProfiler/blob/master/StackExchange.Profiling/Storage/SqlServerStorage.cs#L71)會導致速度放緩? – Chris
查看我的編輯...從查看該表開始已經很長時間了,並且我忘記了* ugh * GUID列中存在聚簇索引。 –
添加了另一個編輯,這次是更新了表格腳本。嘗試一下,讓我知道你是否仍然遇到緩慢的下降。如果您確實有更多問題,請告訴我每個探查器表中有多少行。謝謝! –