为什么只读 AG 辅助数据库上的列存储性能明显较差？

Question

我们有一对 SQL 2019 Enterprise 实例，托管在 Azure 中规格和配置相同的虚拟机中。

它们用于简单的主/辅助可用性组阵列，包含跨少量 AG 的少量数据库。

单个主生产数据库利用由生产代码填充的大型（数十亿行）列存储表，并用于只读分析报告查询 - 这些查询还连接到行存储表以获取附加信息。

我们希望将只读查询卸载到只读 AG 辅助数据库上，以将负载分散到数据库上，因此我们向侦听器提供参数ApplicationIntent=ReadOnly- 这效果很好，并且针对辅助数据库发出查询。

然而，只读查询的持续时间通常比主数据库慢 10 倍。

比较相同的执行计划，我可以看到所有额外的时间都花在读取列存储表上。反复重新运行查询以确保缓存不会对辅助数据库产生任何影响。但在主要方面，我看到了与缓存相关的性能改进，重新运行时立即返回结果。另外，暂时停止AG数据同步也没有任何效果。

比较 IO 统计数据，两者相似。比较列存储对象池和行存储缓冲池中使用的内存，两者也很相似。

这里真的很茫然——我本以为辅助设备的负载要少得多，但资源相同，如果有更好的表现，而不是持续和明显更差的话。

有没有人遇到过这种情况并对我如何改善或至少证明这种情况有任何建议？

Answer 1

我的下面的博客文章详细介绍了一个问题，与已提交的读取相比，在快照隔离或 RCSI 中，可能会导致针对已删除行的 CCI 的查询的总 CPU 和总运行时间显着增加。 即使针对包含已删除行的表的 CCI 查询独立运行且没有任何竞争事务，也会发生这种情况。

由于可用性组辅助节点在底层利用 RCSI，因此针对 CCI 的查询将看到与主节点上的快照隔离或 RCSI 相同的行为。

删除 CCI 中已删除的行将使 RCSI 或快照隔离查询的隔离性能恢复到与已提交读一致。

当使用索引重建或重新组织从 CCI 中删除已删除的行时，请记住，重组使用已删除行的 10% 作为从行组中删除已删除行的默认最小阈值。