爲什麼更好的隔離級是指在SQL Server性能更好

當測量我的查詢性能，我想出了隔離級別之間的依賴和使用時間，這是令人驚訝的對我爲什麼更好的隔離級是指在SQL Server性能更好

READUNCOMMITTED - 409024 
READCOMMITTED - 368021 
REPEATABLEREAD - 358019 
SERIALIZABLE - 348019

左列表提示，並右列是經過的時間（以微秒爲單位）（sys.dm_exec_query_stats.total_elapsed_time）。爲什麼更好的隔離級別提供更好的性這是一個開發機器，不會發生任何併發。由於減少了鎖定開銷，我期望READUNCOMMITTED成爲禁食。

更新：我做了

DBCC DROPCLEANBUFFERS 
DBCC FREEPROCCACHE

發出

衡量這一點，並探查證實是有沒有緩存命中發生。

我當然有這樣的習慣，謝謝提醒。 Remus提供了相當寶貴的意見，但我仍希望瞭解爲什麼我觀察到的現象發生。 – 2010-03-16 10:55:35

首先，您需要在每個隔離級別下重複運行查詢，並對結果進行平均，丟棄最大時間的查詢。這將消除緩衝區預熱影響：您希望所有運行都處於熱緩存中，而不是有一個查詢預熱緩存並相比較而言付出代價。

接下來，您需要確保在實際併發場景下進行測量。如果您將在現實生活中發生更新/插入/刪除操作，那麼您必須將它們添加到您的測試中，因爲它們會在各種隔離級別下極大影響讀取。最後你想要得出的結論是'可序列化的讀取速度最快，可以在任何地方使用它們'，然後在生產中觀察系統融化，因爲所有內容都是序列化的。

除此之外，合法更快的唯一隔離級別是髒讀，因爲它不獲取鎖。讀取已提交的快照（您未測量）也不會獲取鎖定，但由於行版本控制開銷，它確實會影響整體性能。

2010-03-15 22:15:16

請在我的問題中找到更新以解決您的回覆中的一些要點。「髒讀」你的意思是READUNCOMMITTED，對不對？ – 2010-03-15 22:48:22

1）在冷緩存上運行查詢不準確。您的生產查詢不會在冷藏緩存上運行，您將優化一個不切實際的方案，並且不會測量查詢，您實際上是在測量磁盤讀取吞吐量。您還需要在溫暖的高速緩存上測量性能，並跟蹤兩者（冷運行時間，溫暖運行時間）。 2）讀取未提交髒讀。 – 2010-03-15 23:55:51

在一般情況下，對於特定數據只運行一次的大型查詢（數百萬行）的緩存有多相關？ – 2010-03-16 00:08:50

現在我更好地理解隔離級別，我發現更好的隔離級別可以允許一些智能優化。例如，一旦事務讀取一些數據隔離級別可能會規定它應該使用該數據直到最後，而不是嘗試從磁盤重新讀取它們。

我仍然會有興趣閱讀一些這方面的深入瞭解。

2012-01-25 23:33:22

回答