SQL多层JOIN需显式括号或WITH子句控制顺序，LEFT JOIN后右表过滤须写入ON而非WHERE，避免NULL语义错误与字段歧义，驱动表选择和索引优化影响性能。
多层JOIN不加括号会改变结合顺序
SQL标准默认从左到右结合，t1 JOIN t2 ON ... JOIN t3 ON ... 实际等价于 (t1 JOIN t2) JOIN t3，但业务上你可能想先连 t2 和 t3。一旦中间某次连接产生空集或笛卡尔积，后续结果就完全失控。
实操建议：
- 显式用括号控制顺序：
SELECT * FROM t1 JOIN (t2 JOIN t3 ON t2.id = t3.t2_id) ON t1.id = t2.t1_id - 更推荐用
WITH拆解：WITH t23 AS (SELECT ... FROM t2 JOIN t3 ON ...)，再跟t1关联——逻辑清晰、调试方便、MySQL 8.0+ 和 PostgreSQL 都支持 - 避免在同一个
FROM子句里堆叠超过 3 张表，尤其当其中一张是大宽表时
LEFT JOIN后WHERE过滤右表字段等于变相INNER JOIN
这是最隐蔽也最常踩的坑：LEFT JOIN t2 ON t1.id = t2.t1_id WHERE t2.status = 'active' 看似只取活跃记录，实际把所有 t1 中没匹配 t2 的行都干掉了——因为 t2.status 是 NULL，NULL = 'active' 返回 UNKNOWN，被 WHERE 过滤掉。
实操建议：
- 右表过滤条件必须写进
ON：LEFT JOIN t2 ON t1.id = t2.t1_id AND t2.status = 'active' - 如果过滤逻辑复杂（比如带子查询或函数），先用
WITH或临时表预处理右表 - 检查执行计划里
type是否还是ALL或index——说明ON条件没走索引，可能因隐式转换或函数导致
ON条件里用!=或NOT IN会意外丢掉NULL行
ON t1.id = t2.t1_id AND t2.type != 'ignore' 表面看没问题，但只要 t2.type 是 NULL，整个条件就变成 UNKNOWN，这行就不会参与连接。而你本意可能是“只要不是 ignore 就连”，包括 NULL。
实操建议：
- 改用
NOT (t2.type = 'ignore')，它对NULL返回UNKNOWN而非FALSE，但注意仍不包含NULL行 - 真正要包含
NULL，得显式写：COALESCE(t2.type, '') != 'ignore' - 比补丁更可靠的做法：建表时对
t2.type加NOT NULL约束，从源头杜绝歧义
字段来源模糊导致column ambiguously defined错误
连 4 张表后写 SELECT id, name，数据库根本不知道你要的是哪张表的 id。更糟的是，某些引擎（如 MySQL 5.7）可能随机选一个，结果不可控。
实操建议：
- 每层
SELECT都明确别名：SELECT u.id AS user_id, o.id AS order_id - 中间结果用
WITH命名，比如recent_orders比(SELECT ...)更易读且防歧义 - JOIN 多张表时，优先用小表做驱动表，并确保被驱动表的
ON字段有索引——否则即使语法没错，执行时也会因全表扫描爆炸
嵌套本身不危险，危险的是把结合顺序、NULL 语义、字段作用域这些底层规则当成“应该自动懂”的常识。越想一条 SQL 搞定一切，越容易在某个 WHERE 和 ON 的切换点上翻车。
