子查询不能当参数直接传递，而是独立执行的查询单元；应使用WITH复用、JOIN替代相关子查询、应用层传参控制逻辑。
子查询当参数用？别硬套，先看执行计划
SQL 子查询不能直接当“参数”传给外部语句——它不是变量，而是独立执行的查询单元。所谓“参数化模板”，本质是让子查询结果参与条件、计算或连接，而非替换占位符。
常见错误现象：WHERE id = (SELECT user_id FROM config WHERE key = 'current') 看似像参数，但每次执行都会重新跑子查询，且无法复用；更糟的是嵌套过深时，MySQL 可能拒绝优化，PostgreSQL 会提示 more than one row returned。
- 子查询必须返回单值（标量子查询），否则报错
subquery returns more than one row - 若需多值匹配，改用
IN或EXISTS，别强转成= -
WHERE col IN (SELECT ...)在大数据量下可能比JOIN慢，尤其子查询无索引时
用 WITH 替代重复子查询，避免“伪参数”陷阱
想在多个地方引用同一组动态值（比如当前活跃用户列表）？反复写子查询不仅难维护，还可能被数据库多次执行。用 WITH（CTE）才是正解。
使用场景：需要跨多个 SELECT、JOIN 或聚合中复用同一逻辑结果，且该逻辑本身依赖运行时数据（如日期、状态）。
-
WITH active_users AS (SELECT id FROM users WHERE last_login > NOW() - INTERVAL '7 days')后续可多次引用active_users，数据库通常只执行一次 -
SQL Server要求 CTE 前加;（如果前面有语句），MySQL 8.0+和PostgreSQL支持标准语法 - CTE 不是视图，不缓存，但避免了语法重复和潜在执行偏差
WHERE 中的子查询 vs JOIN：性能差在哪
同样想查“订单金额高于该用户平均订单额的订单”，有人写 WHERE amount > (SELECT AVG(amount) FROM orders o2 WHERE o2.user_id = orders.user_id)，有人 JOIN 聚合结果。前者是相关子查询，后者是预计算。
关键差异：相关子查询对主表每行都执行一次，复杂度是 O(n × m)；JOIN 是 O(n + m)，且更容易利用索引。
- 检查执行计划里有没有
DEPENDENT SUBQUERY（MySQL）或SubPlan（PostgreSQL）——这是性能红灯 - 把子查询提前到
FROM或WITH中，再JOIN，往往快几倍 - 注意 NULL 处理：
WHERE col = (SELECT ...)遇到子查询返回NULL整行消失；WHERE col IN (SELECT ...)遇到NULL也不匹配，行为易被忽略
模板化？靠应用层拼接，别让 SQL 自己“猜参数”
真正安全、灵活的“参数化模板”，不在 SQL 内部实现，而在调用方控制。SQL 子查询不是模板引擎，硬塞逻辑只会让可读性和调试性崩塌。
例如，前端选了“最近7天”还是“上月”，不应生成不同子查询，而应由应用传入 start_date 和 end_date 参数，SQL 保持固定结构：
SELECT * FROM orders WHERE created_at BETWEEN ? AND ?
子查询只用于数据逻辑表达（比如“找出所有未付款的关联订单”），不用于控制流程或范围切换。
- 任何试图用子查询模拟 IF/ELSE 或动态列名的行为，最终都会卡在权限、性能或可维护性上
- ORM（如
SQLAlchemy、Knex.js）的 query builder 更适合组装这类逻辑，而不是在 SQL 字符串里拼(SELECT ...) - 最常被忽略的一点：子查询的事务可见性与外层一致，但若跨会话读取配置表（如
config表），得确认隔离级别是否导致读到旧值
