修改参数类型或查询格式后SQL Server慢查询恢复正常的原因是什么？

你遇到的是SQL Server 典型的执行计划缓存退化 + 参数嗅探问题，你提到的两种修改操作本质都是绕开了已经缓存的低效执行计划，强制数据库生成适配当前数据分布的新执行计划，因此耗时恢复正常，具体原理如下：

1. 修改参数类型生效的原因 #

有两层原因共同作用：

• 首先SQL Server的执行计划缓存匹配会校验参数的元数据类型，你将参数从Integer改为String后，JDBC驱动传递给数据库的参数类型发生变化，SQL Server会将其识别为全新的查询，不会复用之前缓存的低效执行计划，会重新生成执行计划。
• 其次如果你的业务表中id_pub/id_type字段的实际类型是字符串类型（比如VARCHAR/NVARCHAR），之前传Integer参数时，数据库会隐式将字段所有值转换为INT类型再和参数匹配，这个过程会直接导致索引失效，触发全表扫描；改为String类型后参数和字段类型匹配，隐式转换消失，索引可以正常使用，查询效率自然恢复。

2. 修改SQL排版生效的原因 #

SQL Server 对执行计划的缓存键是基于查询语句完整字符串的哈希值，查询语句中任何字符层面的差异（包括空格、换行、大小写、注释差异）都会导致哈希值不匹配。你调整了外层SELECT的换行格式后，整条查询字符串和之前缓存执行计划对应的查询字符串不完全一致，数据库会判定这是一条新查询，直接放弃之前因为参数嗅探生成的低效执行计划，基于当前的参数和数据分布生成新的优化执行计划，因此耗时回归正常。

为什么查询会突然变慢？ #

本质是参数嗅探问题：之前某一次执行这条查询时，传入的参数值对应的数据分布非常特殊（比如匹配的行数远高于平均水平），SQL Server基于这个特殊参数生成了适配大结果集的执行计划（比如选择全表扫描而非索引查找），这个执行计划被缓存后，后续所有相同查询字符串、相同参数类型的查询都会复用这个执行计划，哪怕传入的是普通参数，用这个适配大结果集的执行计划也会出现严重的性能下降。

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