嵌套查询在存储过程中变慢大概率是参数嗅探导致执行计划错误复用，可通过查询动态管理视图比对编译值与运行值确认；OPTION(RECOMPILE)虽可规避但增加CPU压力，局部变量隔离更稳妥；同时需检查嵌套结构、索引及统计信息。
嵌套查询在存储过程中变慢，大概率不是嵌套本身的问题，而是参数嗅探（Parameter Sniffing）导致执行计划被错误复用——第一次传入的参数值恰好让优化器选了全表扫描，后续传入高选择性参数时仍硬套这个计划，IO暴增、响应卡死。
怎么确认是参数嗅探惹的祸
别猜，直接查缓存的执行计划和实际运行行为：
- 用
sys.dm_exec_query_stats+sys.dm_exec_sql_text找到该存储过程对应的缓存计划，看plan_handle和last_execution_time - 用
sys.dm_exec_text_query_plan(plan_handle, ...)提取实际执行计划XML，搜索<ParameterList>看编译时用的参数值（ParameterCompiledValue）和当前运行值（ParameterRuntimeValue）是否差异巨大 - 对比两次调用：一次传
@status = 1（90%数据），一次传@status = 0（10%数据），看实际执行计划里是否都是Clustered Index Scan—— 如果后者也扫全表，基本坐实
OPTION(RECOMPILE) 不是万能解药
加 OPTION(RECOMPILE) 确实能让每次执行都重编译，避开参数嗅探，但代价明确：
- 每次执行都要走完整解析 → 编译 → 优化流程，CPU压力陡增，尤其在高并发 OLTP 场景下可能拖垮服务器
- 无法复用计划，意味着统计信息变更后不会自动触发重编译，反而可能错过更优路径
- 只适合低频、参数差异极大、且单次执行耗时远高于编译开销的场景（比如报表类存储过程）
示例写法：SELECT * FROM users WHERE status = @status OPTION(RECOMPILE);
更稳的绕过方式：局部变量隔离参数值
把输入参数赋给局部变量再参与 WHERE 条件，能切断 SQL Server 的“嗅探链”，让优化器失去编译时的真实值参考，转而基于统计信息做通用估算：
- 写法简单：
DECLARE @status_local INT = @status; SELECT * FROM users WHERE status = @status_local; - 效果是让计划变成“平均情况”优化，对中等选择性参数较友好；但若数据分布极端不均（如 99%/1%），可能不如
RECOMPILE精准 - 注意：不能用于
IF判断或WHERE子句外的上下文（如索引提示、分区裁剪），否则会失效 - MySQL / PostgreSQL 没这问题，此法仅限 SQL Server
嵌套查询本身也要同步检查
参数嗅探是诱因，但嵌套结构可能放大问题：
- 子查询若含
IN (SELECT ...)且未命中索引，会被执行 N 次（N=外层结果集行数），此时即使参数值合理，性能照样崩 - 用
EXISTS替代IN，并确保子查询中WHERE字段有索引（如users(status, id)联合索引） - 多层嵌套（>2 层）优先拆成 CTE 或临时表，避免优化器放弃推导中间结果物化时机
- 检查统计信息是否过期：
UPDATE STATISTICS users WITH FULLSCAN;，旧统计会让“估算行数”严重失真，加剧计划误判
真正棘手的是参数值分布 + 嵌套结构 + 统计信息老化三者叠加——单独处理任一环节都可能治标不治本。
