结论：LEFT JOIN后右表过滤必须放ON而非WHERE，否则退化为INNER JOIN；多表关联优先用CTE拆解；IN子查询需防NULL失效，应改用EXISTS。
直接说结论：子查询过滤不能硬塞进 WHERE，尤其在 LEFT JOIN 后；三表以上关联优先用 CTE 拆解，而不是嵌套子查询 + JOIN；多数性能问题根源不是语法写错，而是 ON 和 WHERE 的语义混淆。
LEFT JOIN 后对右表字段加 WHERE 就等于 INNER JOIN
这是线上最常踩的坑。比如你写：
SELECT u.name, o.order_id FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid';
表面上想查“已支付订单的用户”，实际效果是：所有没订单、或订单状态不是 paid 的用户全被过滤掉了——LEFT JOIN 形同虚设。
原因在于执行顺序：FROM → JOIN → WHERE，WHERE 是在连接完成之后才执行的，此时右表字段为 NULL 的行直接被干掉。
- 正确做法：把右表过滤条件移到
ON子句里：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 如果业务上真需要“所有用户 + 仅已支付订单”，就别在
WHERE碰右表字段 - 检查执行计划：若
EXPLAIN的Extra列出现Using where且涉及右表字段，基本可以判定逻辑已变异
三张表以上，别堆 JOIN，先用 CTE 预聚合
写 FROM a JOIN b JOIN c JOIN d 看似直白，但优化器容易误判驱动表，尤其当某张表数据量大、又没索引时，中间结果集可能爆炸。更糟的是，一旦其中一张表是一对多（比如一个用户有多条日志），再连下一张表就会指数级放大行数。
比如要查“每个活跃用户最新一笔订单 + 订单对应的商品类目”，硬写四表 JOIN 容易出错且难调试。
- 推荐拆成两步：先用 CTE 算出每个用户的最新订单 ID（
WITH latest_order AS (SELECT user_id, MAX(created_at) AS max_time FROM orders WHERE status = 'shipped' GROUP BY user_id)） - 再把这个 CTE 当作“虚拟维度表”去 JOIN 用户表和商品表
- CTE 不仅可读性高，MySQL 8.0+ 和 PostgreSQL 还能复用其执行结果，避免重复计算
- 避免用嵌套子查询替代 CTE：子查询在
FROM里必须显式SELECT所有后续要用的字段，漏一个就报ERROR: column "xxx" does not exist
IN (SELECT ...) 要警惕 NULL 和性能断崖
当右表子查询可能返回 NULL 时，IN 会整个失效——这是 SQL 标准行为，不是 bug。例如：
SELECT * FROM users WHERE id IN (SELECT user_id FROM logs WHERE action = 'login');
只要 logs.user_id 里有一个 NULL，整条 IN 判断就变成 UNKNOWN，结果为空。
- 安全替代方案：用
EXISTS（语义清晰、不惧 NULL、通常更快）：EXISTS (SELECT 1 FROM logs l WHERE l.user_id = u.id AND l.action = 'login') - 或者改用
JOIN，但注意去重：SELECT DISTINCT u.* FROM users u JOIN logs l ON u.id = l.user_id WHERE l.action = 'login' - 子查询若带聚合（如
COUNT()），必须配GROUP BY，否则和外层 JOIN 会产生隐式笛卡尔积
真正麻烦的从来不是“会不会写”，而是“有没有意识到 ON 和 WHERE 的边界在哪”、“有没有验证过中间结果集大小”、“有没有确认子查询返回的列是否完整暴露”。这些点不手动查一遍 EXPLAIN 或跑个小样本，光靠语法检查根本发现不了。
