应避免在WHERE子句OR中混用可选与必选条件，优先拆分逻辑、确保关联字段索引有效、用EXISTS(SELECT 1)替代SELECT *、禁用子查询中非必要操作，并注意类型一致以保障索引生效。
WHERE 子句里别在 OR 中混用可选条件和必选逻辑
常见错误是写成 WHERE status = 'active' OR user_id = ?，本意想查“活跃用户”或“指定用户”，结果数据库可能全表扫——因为 OR 破坏索引有效性，尤其当一边字段无索引时。真正要的是“活跃且（可能是某用户或不限）”，得拆成明确分支逻辑。
实操建议：
- 把“可选过滤”提前转为参数判断，用应用层拼接 SQL 或用
CASE WHEN控制执行路径 - 避免
WHERE (condition_a OR condition_b)这类结构，除非两边都有高效索引且基数低 - 用
EXPLAIN看执行计划，重点盯type是否为ref/range，而非ALL
EXISTS 比 IN 更稳，但别在子查询里 SELECT *
IN 遇到子查询返回 NULL 会整个表达式变 UNKNOWN，结果意外为空；EXISTS 只关心行存在性，语义更干净。但很多人写 EXISTS (SELECT * FROM ...)，其实数据库仍要解析所有列，浪费 I/O 和内存。
实操建议：
- 一律用
EXISTS (SELECT 1 FROM ...)，明确告诉优化器“只判存在” - 子查询中避免
ORDER BY、LIMIT、聚合函数等非必要操作 - 若子查询涉及多表关联，先确认驱动表顺序是否合理，
EXISTS的性能高度依赖外层传入值能否命中内层索引
嵌套 SELECT 中的 CASE WHEN 别提前计算无关分支
比如写 SELECT id, CASE WHEN flag = 1 THEN expensive_function() ELSE 'default' END FROM t，即使 flag != 1，某些数据库（如 PostgreSQL 旧版）仍可能预执行 expensive_function()，导致无谓开销。
实操建议：
- 把耗时逻辑封装进自定义函数，并声明为
VOLATILE（PostgreSQL）或DETERMINISTIC（MySQL），让优化器知道是否可跳过 - 优先用条件化 JOIN 替代
CASE内调用函数，例如把函数逻辑移到子查询中，再用LEFT JOIN关联 - 在 MySQL 中，
CASE是短路求值的，但前提是各分支类型兼容；一旦隐式转换发生，可能触发全量计算
相关子查询的 WHERE 条件没下推到内层？检查关联字段索引
像 SELECT * FROM orders o WHERE EXISTS (SELECT 1 FROM items i WHERE i.order_id = o.id AND i.qty > 10)，如果 items.order_id 没索引，每次外层扫描一行，内层就得全表扫一次 items，复杂度爆炸。
实操建议：
- 凡是子查询中用于关联外层的字段（如
i.order_id），必须建索引；复合条件则考虑联合索引，顺序按“等值 → 范围”排列 - MySQL 5.7+ 支持
SEMIJOIN优化，但需关闭optimizer_switch='semijoin=off'才生效，上线前务必验证 - PostgreSQL 中，用
EXPLAIN (ANALYZE, BUFFERS)观察子查询是否被物化（Materialize），物化失败往往意味着缺乏合适索引或统计信息过期
嵌套查询的性能黑洞不在语法多深，而在每一层的条件是否真的被引擎“看见”并下推。最容易被忽略的是：你以为加了索引就安全了，但只要关联字段类型不一致（比如 INT 对 VARCHAR），索引就直接失效。
