SQL创建可用性组并完成迁移后查询加载时间过长问题求助

问题根因定向排查 #

• 首先排查空间数据类型首次加载延迟问题：SQL Server 2019 对geometry/geography等CLR空间类型的首次实例化存在已知冷启动延迟，首次调用空间相关函数、加载大量空间类型字段时，系统需要加载对应的CLR程序集、初始化空间计算组件，这个过程会产生无明确归类的OTHER_WAIT类等待。你反馈单实例测试也能复现问题，已经排除AG同步模式影响，完全符合该特征。
• 排查统计信息迁移遗留问题：从旧版本SQL Server迁移到2019后，原有针对空间字段的统计信息未升级到新版本格式，首次查询时数据库引擎需要动态更新统计信息，会导致首次查询延迟。可以执行以下命令验证：

DBCC SHOW_STATISTICS ('<你的空间表名>', '<空间字段名>')

如果统计信息更新时间为迁移前，或者直方图格式适配旧版本，即可确认该问题存在。

• 排查执行计划缓存问题：虽然你开启了Optimize for Ad hoc workloads参数，但首次查询空间类型语句生成执行计划时，2019默认基数估算器对空间查询的适配可能存在偏差，会拉长计划生成耗时。

可直接落地的解决方案 #

1. 预加载空间类型CLR组件
   在SQL实例启动后、业务请求接入前，手动执行一次轻量空间类型查询触发组件加载，避免用户首次请求触发延迟：

-- 预加载空间CLR组件
SELECT geometry::STGeomFromText('POINT (0 0)', 4326)
GO

可以将该语句加入SQL Server代理的启动作业中，实例重启后自动执行。
2. 全量更新空间相关表的统计信息
使用全扫描模式更新所有包含geometry字段的表的统计信息，适配2019的基数估算器：

UPDATE STATISTICS <你的表名> WITH FULLSCAN

如果表数量较多，可以通过动态SQL批量处理所有包含空间字段的表。
3. 开启空间查询适配跟踪标志
SQL Server 2019 提供专门针对空间查询性能优化的跟踪标志，开启后可解决大量空间字段查询的延迟问题：

-- 实例级别开启TF 6533、TF 6534，优化空间查询性能
DBCC TRACEON (6533, -1)
DBCC TRACEON (6534, -1)

可以将这两个跟踪标志加入到SQL Server的启动参数中，实现永久生效。
4. 验证空间索引有效性
检查查询涉及的空间字段是否创建了符合查询条件的空间索引，如果首次查询未命中索引，会触发全表扫描加载大量空间数据导致延迟，需确认空间索引的边界盒、层级配置和业务查询范围匹配。

效果验证 #

修改完成后重启SQL实例，执行首次业务查询，验证加载时间是否从15秒降低到正常水平，同时查看活动监视器的Other等待占比是否恢复到正常区间。

内容的提问来源于stack exchange，提问作者Roman Schmidt