标准sql中where子句不能直接用外部表字段过滤子查询结果，因子查询是独立作用域，外部字段不可见；仅exists相关子查询或主查询where配合单值子查询可实现外部字段引用。
WHERE里不能直接用外部表字段过滤子查询结果
不能。标准SQL中，WHERE子句只作用于当前查询层级的FROM表，子查询是独立作用域——外部表字段在子查询的WHERE里不可见。常见错误是写成：SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE status = 'shipped' AND user_id = users.id)，这在MySQL、PostgreSQL、SQL Server里都会报错column not found或返回空结果。
真正能“穿透”外部字段的地方只有两个：EXISTS子查询（相关子查询），或主查询的WHERE配合子查询返回值（仅限单值）。
-
EXISTS子查询里可以合法引用外部表字段，比如o.user_id = u.id - 非相关子查询（如
IN (SELECT MAX(id) FROM logs)）只能返回确定单值，才能用于主查询WHERE比较 - 误把关联逻辑塞进子查询
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'。表面看是LEFT JOIN，实际效果等同于INNER JOIN——所有没订单、或订单状态不是'paid'的用户全被WHERE干掉了。
原因在于执行顺序：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且涉及右表字段，说明逻辑已变异
用EXISTS替代IN防NULL陷阱和性能断崖
IN遇到子查询结果含NULL时，整个条件判为UNKNOWN，结果集为空——这不是Bug，是SQL三值逻辑标准行为。比如查“没下过单的用户”，子查询若返回(1, 2, NULL)，user_id NOT IN (1,2,NULL)永远不成立。
EXISTS天然规避这个问题，它只判断是否存在行，不依赖值内容，且多数数据库能利用索引提前终止。
- 写
EXISTS时必须显式关联外层字段，如o.user_id = u.id，漏掉就变成非相关子查询，逻辑全错 - 子查询里统一用
SELECT 1，避免SELECT *触发额外列解析或干扰优化器 - 如果
orders.user_id没索引，EXISTS也会变慢——性能瓶颈在索引，不在语法
三表以上关联优先用CTE拆解，别堆嵌套子查询
硬写FROM a JOIN b JOIN c JOIN d容易让优化器误判驱动表，尤其当某张表数据量大、又没索引时，中间结果集可能爆炸。更糟的是，一对多关系（如一个用户有多条日志）再连下一张表，行数会指数级放大。
比如查“每个活跃用户最新一笔订单 + 订单对应的商品类目”，直接四表JOIN难调试、易出错。应先用CTE预聚合。
- CTE可复用中间结果，避免同一张表被反复扫描（如三次
FROM orders可能扫三遍） - MySQL 8.0+ 和 PostgreSQL 支持CTE物化，而子查询在
FROM里必须显式SELECT所有后续要用字段，漏一个就报column "xxx" does not exist - 递归场景（如角色继承）必须用
WITH RECURSIVE展开权限链，嵌套子查询无法实现
复杂点不在语法本身，而在执行计划是否真走索引、关联字段类型是否一致、以及NULL值如何影响布尔判断——这些地方一漏，结果就静默错，而不是报错。
