使用数据库对象完整SQL引用致查询慢500倍的原因排查

核心问题根源 #

这种性能差异的核心是SQL Server查询优化器对全限定列名的解析逻辑出现偏差，导致执行计划严重退化，具体原因如下：

• 关联逻辑误判，触发重复全表扫描
  当子查询中使用T1.Zdate < database.dbo.SUMMARYTABLE.Zdate时，优化器错误地将外层表的全限定列引用识别为非关联的常量值，而非逐行匹配的外层列。这意味着SUMMARYTABLE的每一行（数百至数千行）都会触发一次对WORKTABLE（700万行）的全表扫描，总扫描量达到数十亿行，自然耗时近500秒。
  而简化为T1.Zdate < Zdate时，优化器能正确识别这是外层更新表的列引用，生成高效的关联执行计划——利用WORKTABLE上的索引（比如(retailer, SalesTier, Zdate)复合索引）快速过滤并计数，单次查询仅需不到1秒。

• 全限定名导致统计信息匹配失效
  SQL Server的优化器依赖统计信息选择执行计划，全限定列名可能导致优化器无法正确关联到对应列的统计数据，进而错误评估数据分布，选择了低效的扫描策略。即使通过Database Tuning Advisor优化了索引，只要优化器无法正确解析列引用，就不会使用这些索引。

• 开发版优化器的边缘场景行为
  SQL Server 2019开发版虽功能与企业版一致，但在部分边缘解析场景下，优化器规则可能存在细微差异。全限定列名的写法恰好触发了这种未预期的优化路径，导致执行计划退化。

验证与解决建议 #

1. 对比执行计划
   查看两种查询的执行计划：慢查询会显示对WORKTABLE的多次全表扫描，快查询则是利用索引的范围扫描+嵌套循环/哈希关联。
2. 优化列引用方式
   给外层表起别名，用别名引用列，避免全限定名的歧义，比如：

   UPDATE S
   SET S.LifetimeCount = (select count(*) from database.dbo.WORKTABLE as T1 
   WHERE T1.retailer = S.retailer
   and T1.SalesTier = 1
   and T1.Zdate < S.Zdate)
   FROM database.dbo.SUMMARYTABLE S
   

3. 更新统计信息
   强制更新WORKTABLE的统计信息，确保优化器获取准确数据分布：

   UPDATE STATISTICS database.dbo.WORKTABLE WITH FULLSCAN;
   

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