2012-12-03 47 views
4

我們以兩種方式使用小型探查:MiniProfiler SqlServerStorage變得很慢

  1. 在與彈出開發商機
  2. 與SqlServerStorage存儲到MS SQL
我們分期/生產環境

幾周後,我們發現寫入概要分析數據庫需要很長時間(秒),並導致網站上的實際問題。截斷所有分析器表可以解決問題。

通過查看SqlServerStorage代碼,它看起來插入也做了檢查,以確保具有該ID的行不存在。這是爲了確保DB不可知的代碼?這看起來會隨着行數的增加而引入巨大的懲罰。

我該如何去除性能分析器的性能損失?有沒有人遇到這種緩慢?或者是我們做錯了什麼?

歡迎任何幫助或建議。

回答

5

嗯,看起來我在創建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

我會高度建議刪除所有現有表並重新運行更新的腳本。

+0

我可能是錯的,但不會索引減慢插入?或者是否需要索引的後續插入查找?我認爲[this](https://github.com/SamSaffron/MiniProfiler/blob/master/StackExchange.Profiling/Storage/SqlServerStorage.cs#L71)會導致速度放緩? – Chris

+0

查看我的編輯...從查看該表開始已經很長時間了,並且我忘記了* ugh * GUID列中存在聚簇索引。 –

+0

添加了另一個編輯,這次是更新了表格腳本。嘗試一下,讓我知道你是否仍然遇到緩慢的下降。如果您確實有更多問題,請告訴我每個探查器表中有多少行。謝謝! –

相關問題