标量子查询在WHERE中与参数共用时性能不稳定，主因是子查询独立编译、不参与参数绑定，且易受索引缺失、返回多行、值分布不均影响；需建索引、加TOP 1/ORDER BY、或改用变量预查、CTE、JOIN等显式优化手段。
子查询不能当参数用，但可以和参数化共存——关键在执行计划是否稳定、复用是否合理。
WHERE 中的标量子查询 + 参数，为什么有时快有时慢？
常见错误现象：WHERE id = (SELECT TOP 1 user_id FROM config WHERE key = @config_key) 看似简洁，但每次执行都触发一次子查询，且该子查询无法被参数敏感计划（PSP）自动适配——因为子查询本身不参与参数绑定，它的执行计划是独立编译的。
真正影响性能的是：子查询是否走索引、是否返回单行、是否被缓存。若 config.key 没有索引，或 @config_key 值分布极不均匀（比如 99% 查询 'current'，1% 查询 'backup'），SQL Server 可能为所有调用复用同一个计划，导致某类参数下严重低效。
- 确保子查询字段有索引：
CREATE INDEX IX_config_key ON config(key) INCLUDE(user_id); - 强制单行语义：加
TOP 1并配合ORDER BY，避免subquery returns more than one row错误 - 如该配置值极少变动，考虑用变量先查出再代入主查询，而非嵌套子查询
IN / EXISTS 替代子查询时，参数化怎么写才不踩坑？
用 WHERE col IN (SELECT id FROM @table_var) 是错的——表变量不支持直接用于 IN 子句右侧；而 WHERE col IN (@p1, @p2, @p3) 又无法应对动态长度列表。
正确路径只有两条：
- 用临时表 +
INSERT INTO #tmp SELECT ...，再JOIN #tmp——适合列表较大、需多次引用的场景 - 用字符串拆分函数（如
STRING_SPLIT(@id_list, ',')）+EXISTS——注意 SQL Server 2022 默认启用STRING_SPLIT的内联展开优化，但若@id_list长度超 8000 字符，可能退化为多行执行 - 避免
WHERE col IN (SELECT ...)跟参数混合使用：子查询无索引 + 外层参数变化大 = PSP 失效高发区
WITH CTE + 参数，能规避参数敏感计划问题吗？
不能自动规避，但能显著降低 PSP 触发概率。因为 CTE 在逻辑上“提前定义数据集”，让优化器更容易识别出参数影响的边界。
例如：
WITH target_users AS (
SELECT id FROM users
WHERE status = @status
AND last_login >= DATEADD(day, -@days, GETDATE())
)
SELECT o.* FROM orders o
INNER JOIN target_users u ON o.user_id = u.id;这个结构中，@status 和 @days 同时作用于 CTE，SQL Server 2022 的 PSP 机制会更倾向于为这组参数组合生成独立计划（尤其当 status 列直方图显示明显倾斜时）。
- CTE 必须是“可内联”的——不能含聚合、TOP、窗口函数等阻断内联的操作，否则会被物化，失去 PSP 适配机会
- 避免在 CTE 内部再嵌套参数化子查询，那等于把问题藏得更深
- 用
OPTION (RECOMPILE)强制重编译，仅在参数值差异极大且执行频次极低时考虑（比如后台批处理）
强制参数化（FORCED）对含子查询的语句有效吗？
基本无效。根据 Microsoft Learn 文档，强制参数化明确排除以下情况：SELECT 列表中的子查询、WHERE 中的标量子查询、以及所有出现在 IN 或 = 右侧的子查询。
也就是说，WHERE x = (SELECT ...) 或 WHERE x IN (SELECT ...) 里的子查询部分，SQL Server 永远不会把它里面的文字常量转成参数——它始终按字面量处理，不受 ALTER DATABASE SET PARAMETERIZATION FORCED 影响。
- 别指望开启 FORCED 就能让子查询“参数化”，它只管主语句的 WHERE/JOIN 条件中的字面量
- 子查询本身的性能瓶颈（如无索引、多行返回）必须单独治理，不能依赖数据库级参数化开关
- 真正要控制子查询行为，靠的是显式改写（CTE / JOIN）、索引、或应用层预查
最易被忽略的一点：子查询是否真的需要“实时执行”？很多所谓“动态参数”，其实只是配置项，查一次缓存起来比每次跑子查询更稳、更快、更可控。
