本文可協助您解決在唯讀次要複本上遇到查詢效能問題的問題。
原始產品版本：SQL Server
原始 KB 編號： 4040549
徵兆
假設您有Microsoft SQL Server Always On 可用性群組成員資料庫，其中包含一或多個具有 clustered row-store 索引的大型數據表。 一或多個大型數據表的查詢會比次要複本更快速地在主要複本上完成。
注意事項
- 查詢會導致對數據表的大部分進行叢集索引掃描。
- 查詢會使用 NOLOCK 提示。
- 執行計劃運算子和運算符順序與快速和緩慢的執行順序相同。
- 查詢 sys.dm_db_index_physical_stats 會顯示叢集索引的重大片段。
- 從 AlwaysOn 可用性群組取消加入資料庫可改善相同 （先前） 次要復本實例的效能，使其類似於主要複本上的效能。
原因
強制執行快照集隔離時， 會忽略NOLOCK 提示。 主要複本與次要複本之間的執行持續時間不一致，因為 預設不會強制執行快照隔離的主要複本上會忽略NOLOCK 提示，但不會在默認強制執行快照集隔離的主要複本上忽略。 這會導致叢集索引的掃描在次要複本上強制執行索引鍵順序。 在主要復本上 ，NOLOCK 提示會優先使用，而且會影響行為。 當叢集索引高度分散時，只讀次要複本上掃描的索引鍵順序強制會導致 SQL Server 發出單頁讀取。 但在主要復本上，SQL Server 會執行配置單位掃描，以讀取每個 IO 要求的多個頁面。
解決方法
若要修正此問題，請重建主要復本上的索引。 此作業接著會傳播至次要複本。 如需詳細資訊，請參閱 使用 AlwaysOn 可用性群組進行索引維護的建議。
其他相關資訊
和 SET STATISTICS IO 執行計劃 實際 I/O 統計數據資訊可能無法協助診斷此問題發生時。 這些會提供讀取頁面數目的相關信息，但不會提供讀取頁面的IO作業數目。
相反地，請先尋找叢集索引的片段。 此外，當您使用可用性群組中的資料庫執行查詢時，可能會收集 效能監視器 IO 讀取作業/秒和 IO 讀取位元組/秒行程計數器兩次，並在資料庫從可用性群組中移除資料庫並上線時，再次從相同的實例收集。 如果索引片段造成次要複本上的單頁讀取，但未在主要複本上讀取，當資料庫不在可用性群組時，您會預期會看到較大的讀取 IO/秒，以及較小的讀取位元組數/秒。
此外，此行為可能會在所有環境中發生，但不會明顯顯現出來。 例如，可以處理 IO/秒層級增加且延遲最低且類似的輸送量的 IO 子系統可能會讓此問題不受注意到。