动态sql中子查询无法访问外层变量，必须通过安全拼接或cte/lateral等结构传递参数，并显式处理null陷阱。
动态SQL里不能把参数“透传”进嵌套子查询的WHERE或SELECT中——参数只能在最外层拼接，子查询内部无法直接引用外部变量，必须靠显式值传递或结构重写。
动态SQL中子查询无法访问外层变量
无论MySQL的PREPARE还是PostgreSQL的EXECUTE，子查询都处于独立执行上下文。你在外面SET @user_id = 123，子查询里写WHERE u.id = @user_id会报错（MySQL）或根本不可见（PostgreSQL）。这不是语法问题，是作用域隔离设计。
- MySQL错误示例：
Unknown column '@user_id' in 'where clause'或Must declare the scalar variable "@user_id"（SQL Server） - PostgreSQL中
$1等占位符只对外层语句生效，子查询里写WHERE id = $1会被当作未绑定参数处理，运行时报there is no parameter $1 - 唯一可行路径：把变量值作为字面量拼进子查询字符串，但必须严格校验、转义、加引号
安全拼接子查询参数的实操要点
想让子查询“知道”某个值，得把它当成字符串的一部分拼进去，而不是指望变量穿透。但硬拼=高危，必须控制输入源和格式。
- 只允许白名单表名/字段名：用
IN ('orders', 'users', 'logs_2024')校验后再拼，禁用用户直输 - 数值型参数直接拼（如
WHERE status =CONCAT(?, '')），但需提前CAST(? AS SIGNED)防注入 - 字符串参数必须单引号包裹+双单引号转义（MySQL）或
quote_literal()（PostgreSQL），例如CONCAT('''', REPLACE(@name, '''', ''''''), '''') - 日期参数统一转为
'2026-08-27'格式再拼，避免NOW()之类函数混入子查询导致执行计划失效
比拼接更安全的替代方案
拼接永远有缝隙，优先用数据库原生支持的参数化结构绕过子查询参数难题。
- PostgreSQL用
WITH+ 参数占位符：WITH filter AS (SELECT * FROM logs WHERE $1::text = 'all' OR created_at >= $2) SELECT * FROM users WHERE id IN (SELECT user_id FROM filter) - SQL Server用
sp_executesql传参，把子查询逻辑提到CTE里：EXEC sp_executesql N'WITH top_n AS (SELECT TOP (@n) id FROM scores ORDER BY score DESC) SELECT * FROM users u JOIN top_n t ON u.id = t.id', N'@n INT', @n = 5 - MySQL 8.0+用
LATERAL关联子查询（需主表先查出来）：SELECT u.name, s.cnt FROM users u LEFT JOIN LATERAL (SELECT COUNT(*) cnt FROM orders WHERE orders.user_id = u.id AND status = ?) s ON true——这里?由外层绑定，LATERAL确保u.id可被子查询引用
最容易被忽略的NULL陷阱
哪怕你把参数安全拼进去了，子查询里用= @param依然可能静默失效——因为@param为NULL时，整个条件变成UNKNOWN，整行被过滤。这不是bug，是SQL三值逻辑的必然结果。
- 正确写法是显式判断：
WHERE (@param IS NULL OR column = @param)，拼接时也得照此展开 - 若拼的是
IN子查询，绝不要写WHERE id IN (SELECT id FROM t WHERE status = @status)，而要改成WHERE EXISTS (SELECT 1 FROM t WHERE t.id = outer.id AND (@status IS NULL OR t.status = @status)) - 所有拼接生成的子查询，必须人工检查是否覆盖了
IS NULL分支，否则上线后数据就“少一半”，还查不出原因
