為什麼只讀 AG 輔助數據庫上的列儲存性能顯著下降？
我們有一對 SQL 2019 Enterprise 實例託管在 Azure 中相同規格和配置的 VM 中。
它們用於簡單的主/輔助可用性組陣列，包含跨少量 AG 的少量數據庫。
單個主生產數據庫利用由生產程式碼填充的大型（數十億行）列儲存表，並用於只讀分析報告查詢 - 這些查詢還連接到行儲存表以獲取更多資訊。
我們希望將只讀查詢解除安裝到只讀 AG 輔助伺服器上，以分散數據庫上的負載，因此我們使用
ApplicationIntent=ReadOnly參數向偵聽器發送 - 這很有效，並且查詢是針對輔助伺服器發出的。但是，只讀查詢的持續時間通常比主數據庫慢 10 倍。
比較相同的執行計劃，我可以看到所有額外的時間都用於讀取列儲存表。反復重新執行查詢以確保記憶體不會對輔助節點產生任何影響。但在最初，我看到了與記憶體相關的性能改進，在重新執行時立即返回結果。此外，暫時中止 AG 數據同步也沒有任何效果。
比較 IO 統計數據，它們都相似。比較列儲存對像池和行儲存緩衝池中使用的記憶體，兩者相似。
在這裡真的不知所措-我本來預計輔助伺服器的負載要小得多，但具有相同的資源，如果有更好的表現，而不是始終如一且明顯更差的話。
有沒有人遇到過這種情況並對我如何改善或至少證明這種情況有任何建議？
我在下面的部落格文章詳細介紹了一個問題，與已送出的讀取相比，當在快照隔離或 RCSI 中針對已刪除行的 CCI 進行查詢時，該問題可能會導致總 CPU 和總執行時間顯著增加。 即使針對已刪除行的表的 CCI 查詢在沒有任何競爭事務的情況下單獨執行時，也會發生這種情況。
#SQLServer 快照隔離級別 - 將查詢 CPU 時間和執行時間增加 8 倍！
因為可用性組輔助在後台利用 RCSI，所以針對 CCI 的查詢將看到與主伺服器上的快照隔離或 RCSI 相同的行為。
刪除 CCI 中的已刪除行將使 RCSI 或快照隔離查詢的性能與已送出的讀取保持一致。
當使用索引重建或重新組織從 CCI 中刪除已刪除的行時，請記住，reorg 使用 10% 的已刪除行作為從行組中刪除已刪除行的預設最小門檻值。