CONTAINSTABLE内连接、双引号全文条件的SQL查询在特定库运行过慢排查

核心判断 #

这个问题90%以上是目标数据库的统计信息失准、全文检索配置错位或者兼容级别异常导致，和你的单变量测试现象完全自洽，和待处理数据量无关。

触发逻辑匹配 #

四个条件同时满足才触发超时，任意移除一个条件就恢复正常，本质是查询优化器在这个特定组合下选中了错误的执行计划：

• 带双引号的全文检索条件，在SQL Server的执行规则里属于精确短语类模糊匹配，和不加引号的自由文本检索走完全不同的执行分支；
• 当同时带上InsuredOrganisationId IS NOT NULL的过滤条件时，正常高效逻辑应该是先把Claim表过滤成小结果集，再去匹配CONTAINSTABLE的结果，但优化器因为统计信息不准，会错误选择“先拉全量CONTAINSTABLE结果，再逐行关联校验WHERE条件”的低效路径；
• 任意去掉一个触发条件，都会让优化器跳过这个错误的计划分支：
  • 去掉双引号：全文检索的结果基数估算值变化，会触发优化器选择正确的关联顺序
  • 去掉WHERE子句：没有额外过滤步骤，无论怎么关联都不会触发低效路径
  • 去掉JOIN逻辑：没有跨对象的计划选择环节，单独运行任意对象速度都正常
  • 切换到其他数据库实例：不存在目标库的统计/配置异常，生成的执行计划完全正确

可直接落地的排查修复步骤 #

• 在目标库重建所有相关统计信息，执行以下语句：

  -- 全量更新Claim表的统计信息
  UPDATE STATISTICS Claim WITH FULLSCAN;
  -- 重建绑定Claim表的全文目录
  EXEC sp_fulltext_catalog 'Claim表对应的全文目录名', 'rebuild';
  

• 强制指定正确的执行顺序验证问题：在原查询末尾加OPTION (FORCE ORDER)，如果加了查询提示后速度回到1秒内，即可100%确认是统计信息失准导致的执行计划选错。
• 对比目标库和正常数据库的兼容级别：如果目标库兼容级别远低于其他实例，会触发老版本SQL Server全文检索关联的已知性能bug，调整到和正常实例一致的兼容级别即可解决。

内容的提问来源于stack exchange，提问作者Simon Green