對帶有索引和海量數據的表進行頻繁的 DML 操作會影響 SELECT 查詢性能嗎？
如果我對具有大量數據的表進行頻繁的 DML（插入、更新、刪除）操作，並且具有聚集和非聚集索引。它會影響在索引列上具有 where 條件的該表上的 SELECT 查詢的性能，還是會保持與沒有 DML 操作時相同的性能？
此連結說 UpdateStatistics 確實阻止了 Select 查詢。DML 操作也會導致 UpdateStatistics。它說“您唯一無法控制的情況是在您的數據庫上啟用了 AUTO_UPDATE_STATISTICS 並且禁用了 AUTO_UPDATE_STATISTICS_ASYNC。”。那麼改變這些值是最好的解決方案嗎？
注意： 我將為不應被鎖阻塞的 SELECT 查詢使用隔離級別（未送出讀）。
首先是對術語的評論：DML（數據操作語言）包括 SELECT。當你說 DML 指的是 INSERT、UPDATE 和 DELETE 時，我有一種感覺。我將這些稱為“修改聲明”。
您還說您執行“預設隔離級別（讀取未送出）”。這是不正確的。預設隔離級別是 Read Committed，而不是 Read Uncommitted。
Read Committed 確實被排他鎖阻塞了，排他鎖是通過數據修改語句獲取的。這是 Read Committed 的預設行為，但您可以通過將數據庫設置 read committed snapshot 更改為 ON (RCSI) 來重新配置該行為。由於 RCSI 讀取器不會被修飾符阻塞，它們將獲得該行的最後送出版本，而不是等待。（順便說一句，對於 Azure SQL 數據庫，RCSI 預設為 ON。）
不用擔心更新統計資訊。它不會阻止讀者。您在更新統計資訊的同時引用了 INDEX REORGANIZE 的那篇博文。UPDATE STATISTICS 本身不會阻止讀者。我剛剛通過對索引的統計資訊執行更新統計資訊來驗證這一點，並且我同時使用該索引/統計資訊執行了 SELECT，多次執行，沒有任何阻塞提示。