子查询中必须与主查询统一参数化，不可单独拼接；所有变量需在sp_executesql或execute中一次性声明并传值，避免字符串拼接导致注入。
子查询里不能直接用参数占位符？
不是不能，而是必须和宿主SQL一起绑定。常见错误是把子查询单独拎出来拼字符串，比如在 sp_executesql 里只给外层SQL传参，子查询却用 +' WHERE id = '+CAST(@uid AS VARCHAR) 拼进去——这等于开了SQL注入后门。
真正安全的做法：整个含子查询的SQL语句作为模板，所有变量（无论出现在主查询还是子查询里）都统一列在 sp_executesql 的参数声明和值列表中。
-
EXEC sp_executesql @sql, N'@uid INT, @status NVARCHAR(20)', @uid = @user_id, @status = @input_status—— 子查询里的@uid和@status必须在这里声明并传值 - 如果子查询嵌套多层（比如
IN (SELECT ... WHERE x IN (SELECT ...))），所有变量仍只声明一次，由数据库引擎统一解析作用域 - Oracle/PostgreSQL 同理：
EXECUTE 'SELECT * FROM t WHERE id IN (SELECT uid FROM log WHERE status = $1)' USING :status，$1覆盖内外两层
IN / = / EXISTS 子查询对参数的要求差异
参数化本身不解决语义问题，但错误的子查询类型会让参数失效甚至报错。
-
WHERE id IN (SELECT user_id FROM logs WHERE status = @status)：子查询必须单列、无NULL；若@status为空或为NULL，结果可能全空或逻辑异常 -
WHERE id = (SELECT TOP 1 user_id FROM logs WHERE status = @status ORDER BY ts DESC)：要求严格单行单列，@status若匹配多行，运行时报Subquery returns more than 1 row -
WHERE EXISTS (SELECT 1 FROM logs WHERE user_id = t.id AND status = @status)：最宽松，@status传什么都不会因行数或NULL崩掉，推荐优先用
Go/Python等应用层动态拼子查询时怎么管参数
不能靠ORM自动补全子查询参数——多数ORM只处理主查询占位符。你得手动同步维护参数顺序和数量。
- PostgreSQL +
pgx：子查询每加一个$N，就要往[]interface{}切片 append 一个对应值，N从1开始递增 - 示例：
base += " AND id IN (SELECT uid FROM events WHERE ts >= $"+strconv.Itoa(len(params)+1)+")"，然后params = append(params, startTime) - MySQL 不支持位置参数嵌套，改用命名参数（
:start_time），但驱动必须支持（如go-sql-driver/mysql不原生支持，需用sqlx或自行映射） - 切忌用
fmt.Sprintf把用户输入直接塞进子查询字符串——哪怕只是数字，也绕过类型校验
CTE替代动态子查询更稳？
是，尤其当子查询逻辑固定但过滤条件可变时。CTE让SQL主体静态化，参数只作用于 WHERE 分支，执行计划更易复用。
- PostgreSQL 示例：
WITH filtered AS (SELECT * FROM logs WHERE ($1::text = 'all') OR (status = $1)) SELECT name FROM users WHERE id IN (SELECT user_id FROM filtered) - 注意显式类型转换：
$1::text防止字符串参数被推断为unknown类型，导致索引失效 - SQL Server 不支持
$1，改用@p1，且 CTE 中不能直接引用存储过程变量，需通过sp_executesql传入 - CTE 不物化，若子查询被多次引用（如 JOIN 两次），性能未必优于临时表；PG 12+ 可加
MATERIALIZED强制物化
最易被忽略的点：子查询里用到的字段，即使加了索引，也可能因外层 JOIN 顺序或统计信息不准被忽略——参数化只解决安全，不解决执行计划误判。
