使用 READ UNCOMMITTED 隔離級別的最佳情況

眾所周知，READ UNCOMMITTED 是最低的隔離級別，其中可能會產生臟讀和幻讀等情況。何時是使用此隔離級別的最佳時間以及可能出於什麼原因使用它？

其實我之前看過答案，但我無法完全理解它，因為沒有足夠的例子。

我在從 SSMS 查詢生產數據庫時使用READ_UNCOMMITTED（或NOLOCK），但不經常從應用程式碼中查詢。這種做法（連同 MAXDOP 1 查詢提示）有助於確保用於數據分析和故障排除的臨時查詢不會影響生產工作負載，但要了解結果可能不正確。

可悲的是，我看到READ_UNCOMMITTED/NOLOCK在生產程式碼中廣泛使用，以避免以犧牲數據完整性為代價的阻塞。正確的解決方案是行版本控制隔離級別（SNAPSHOT或READ_COMMITTED使用READ_COMMITTED_SNAPSHOT數據庫選項ON）和/或註意查詢和索引調整。

我最近對一個 proc 進行了程式碼審查，其中唯一的更改是刪除NOLOCK，因為它有時會返回錯誤的結果。刪除NOLOCK是一件好事，但是，知道失去或重複的行通常發生在大型表的分配順序掃描期間，我建議還進行重構以使用一種UNION ALL技術來促進有效的索引使用。查詢現在在幾毫秒內執行並得到正確的結果，這是世界上最好的。

引用自：https://dba.stackexchange.com/questions/206485