子查询在IN、=、EXISTS中语义不同：IN要求单列且避NULL，=要求单行单列，EXISTS最安全；动态SQL须用绑定变量防注入，慎拼字符串；WITH+参数化可替代多数动态子查询。
WHERE 子句里怎么安全拼接子查询条件
直接字符串拼接 WHERE id IN (SELECT user_id FROM logs WHERE status = 'active') 看似简单，但一旦子查询逻辑变复杂（比如要加 ORDER BY、LIMIT 或嵌套聚合），就容易报错或返回意外结果。关键是：子查询在 IN、=、EXISTS 中的语义完全不同，不能随便互换。
-
IN要求子查询只返回单列，且不能有NULL（否则整条判断为UNKNOWN） -
=要求子查询严格返回 1 行 1 列，多行会报Subquery returns more than 1 row -
EXISTS最安全——只关心是否存在匹配行，不依赖返回值内容，也规避了NULL陷阱
用 EXECUTE IMMEDIATE 构建动态子查询时怎么防注入
Oracle 或 PostgreSQL 的动态 SQL 很容易把用户输入直接拼进子查询字符串，比如 'SELECT id FROM users WHERE name = ''' || user_input || ''''。只要 user_input 是 ' OR 1=1 --，整个条件就失效了。
- 优先用绑定变量：PostgreSQL 用
EXECUTE 'SELECT ...' USING param1, param2；Oracle 用USING子句传参 - 如果必须拼字符串（比如动态表名），对输入做白名单校验：
REGEXP_LIKE(table_name, '^[a-z_][a-z0-9_]{2,29}$') - 避免在子查询里拼接
ORDER BY字段名——改用 CASE 预定义排序逻辑，防止字段名注入
WITH 子句 + 参数化视图能替代大部分动态子查询吗
能，而且更清晰、更易测试。与其在应用层拼 SQL，不如把可变逻辑下沉到 CTE 层，用参数控制分支。比如按时间范围过滤日志，不用拼 BETWEEN '2024-01-01' AND '2024-06-30'，而是：
WITH filtered_logs AS (
SELECT * FROM logs
WHERE
($1::text = 'all')
OR (created_at >= $1::date AND created_at < $2::date)
)
SELECT u.name FROM users u
WHERE u.id IN (SELECT user_id FROM filtered_logs);这样 SQL 本身是静态的，参数由调用方传入，数据库还能复用执行计划。
-
$1、$2是 PostgreSQL 占位符；Oracle 对应:p_start、:p_end - 注意类型强制转换：字符串参数传进来时，必须显式转成
date或int，否则可能走全表扫描 - CTE 不是视图，不会物化——如果子查询被多次引用，考虑加
MATERIALIZED（PG 12+）
子查询作为条件时，为什么加了索引还是慢
常见错觉：给子查询里的字段加了索引，主查询就快了。实际瓶颈常在“驱动顺序”上。比如 SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE region = 'CN')，如果 customers.region 匹配太多行，数据库可能先执行子查询拿到几千个 id，再对 orders 做几千次索引查找——比直接 JOIN 还慢。
- 用
EXPLAIN看执行计划，重点观察子查询是否被“展开”（flattened）；没展开说明优化器放弃了重写 - 把
IN改成EXISTS，往往触发更好的连接策略：EXISTS (SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.region = 'CN') - 如果子查询结果集稳定（比如地区白名单），考虑物化成临时表并建索引，而不是每次重算
子查询动态性真正的难点不在语法拼接，而在执行路径是否可控——参数传进去之后，数据库到底怎么执行、走哪条索引、要不要物化，这些细节一不留神就被隐藏在“看起来能跑通”的 SQL 后面。
