使用参数执行带LIKE的SQL查询过慢问题咨询

嘿，我太懂这种崩溃的感觉了——硬编码跑5秒，参数化直接卡5分钟，简直离谱！咱们来唠唠这到底是咋回事，以及怎么快速解决。

核心原因：执行计划的差异 #

这种情况大概率是SQL优化器在处理硬编码和参数化查询时，生成了完全不同的执行计划：

• 当你用硬编码值'20180506%'时，优化器能直接拿到这个具体值，结合表的统计信息，精准估算匹配的行数，然后选择最优的执行方式（比如用索引seek快速定位数据）。
• 但换成参数后，优化器可能会触发参数嗅探，或者因为统计信息过时，错误估算了匹配行数，导致选了糟糕的执行计划（比如全表扫描），速度直接拉胯。

一步步解决问题 #

1. 先更新统计信息试试

很多时候，慢查询都是因为统计信息过时，优化器摸不清表的数据分布。执行这两句更新统计信息的命令：

UPDATE STATISTICS sgmc.q9a_p_sot;
UPDATE STATISTICS sgmc.q9a_p_cot;

更新完再跑参数化查询，说不定直接就快起来了。

2. 让参数化查询复用最优执行计划

如果更新统计信息没用，那就强制优化器每次都根据实际参数值生成计划，用OPTION (RECOMPILE)就行。修改后的参数化查询大概是这样：

SELECT list, useralph26, COUNT(*) total 
FROM sgmc.q9a_p_sot sot (NOLOCK)
JOIN sgmc.q9a_p_cot cot ON sot.record_id = cot.record_id 
WHERE suppression = 'NOT' 
  AND response LIKE @dateParam + '%' 
GROUP BY useralph26, list 
ORDER BY list, useralph26
OPTION (RECOMPILE);

（顺便把旧的连接语法改成JOIN了，可读性更好）
每次执行都会重新生成计划，虽然有一点点编译开销，但对比5分钟的等待，这点代价完全可以忽略。

3. 检查索引是否到位

看看response字段有没有合适的索引？如果没有，优化器只能全表扫。可以创建一个覆盖索引，让查询不用回表就能拿到所有需要的数据：

CREATE NONCLUSTERED INDEX IX_q9a_p_sot_response_include 
ON sgmc.q9a_p_sot (response)
INCLUDE (record_id, useralph26, list);

另外，连接字段record_id在两个表上都应该有索引吧？如果没有的话，连接时的表扫描也会拖慢速度，记得补上。

4. 避开参数嗅探的坑

如果你的参数化查询第一次用的是一个匹配行数极少/极多的参数，优化器生成的计划会一直复用，导致其他参数执行变慢。这时候可以用局部变量“绕开”参数嗅探：

DECLARE @localDate VARCHAR(20) = @dateParam;
SELECT list, useralph26, COUNT(*) total 
FROM sgmc.q9a_p_sot sot (NOLOCK)
JOIN sgmc.q9a_p_cot cot ON sot.record_id = cot.record_id 
WHERE suppression = 'NOT' 
  AND response LIKE @localDate + '%' 
GROUP BY useralph26, list 
ORDER BY list, useralph26;

优化器会基于更通用的统计信息生成计划，不会被某个特殊参数带偏。

总结 #

先从更新统计信息和检查索引入手，这是最常见的解决办法；如果不行，再试试RECOMPILE或者局部变量，基本就能搞定这个问题了。

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