LEFT JOIN 同一表多次时必须为每次关联指定唯一别名，否则报错“table name specified more than once”；ON条件须严格绑定对应别名字段，WHERE中误用IS NOT NULL会隐式转为INNER JOIN，且需确保索引覆盖各JOIN条件。
LEFT JOIN 同一个表多次时，必须给每个实例起别名
不加别名会导致 SQL 解析失败，报错类似 ERROR: table name "xxx" specified more than once。数据库无法区分你是在引用同一个物理表的多个逻辑视角，所以每个 JOIN 都要配一个唯一别名。
常见错误写法：LEFT JOIN users ON orders.user_id = users.id LEFT JOIN users ON orders.shipper_id = users.id —— 这里 users 出现两次，没别名，必报错。
正确做法是为每次 JOIN 的表指定不同别名，比如 u1、u2：
SELECT o.id, u1.name AS buyer_name, u2.name AS shipper_name FROM orders o LEFT JOIN users u1 ON o.user_id = u1.id LEFT JOIN users u2 ON o.shipper_id = u2.id
ON 条件必须绑定到对应别名，不能混用
别名不只是“取个代号”，它决定了 ON 子句中字段的归属。一旦用了 u1，所有该次 JOIN 中涉及的字段都得带 u1. 前缀；用 u2 就得用 u2.。写成 o.user_id = users.id 或 o.shipper_id = u1.id 都会出错或查出错数据。
-
ON o.user_id = u1.id✅（匹配买家） -
ON o.shipper_id = u2.id✅（匹配发货人） -
ON o.shipper_id = u1.id❌（逻辑错位，可能把发货人当成买家查） -
ON o.user_id = users.id❌（users未声明，语法错误）
多次 LEFT JOIN 同表时，NULL 值处理要提前想清楚
每次 LEFT JOIN 都独立判断匹配结果，哪怕前一次没匹配上，后一次仍会尝试。但若关联字段本身是 NULL（比如 shipper_id IS NULL），对应那条 LEFT JOIN 的结果整行都是 NULL —— 不会跳过，也不会影响前面的 JOIN。
典型场景：订单可能没有指定发货人，此时 u2.name 是 NULL，但 u1.name 依然有效。如果后续在 WHERE 中写了 u2.name IS NOT NULL，就实际变成了 INNER JOIN 效果，这点极易被忽略。
- 需要保留所有订单？确保 WHERE 中不意外过滤掉 NULL 关联行
- 想只看有发货人的订单？用 WHERE
u2.id IS NOT NULL，比u2.name IS NOT NULL更安全（避免 name 字段本身允许 NULL） - 字段别名冲突？SELECT 中给同名字段显式起别名，如
u1.email AS buyer_email,u2.email AS shipper_email
性能隐患：重复扫描同一张大表，索引是否覆盖所有 JOIN 条件？
数据库通常会对每次 JOIN 单独走一遍索引查找。如果 users 表很大，而你 JOIN 了 3 次，且每次 ON 条件字段都没有单独索引（比如只有 (id) 主键，但 ON 的是 user_code 或 external_id），就会触发多次全表扫描或慢索引查找。
检查方法：用 EXPLAIN 看执行计划，确认每行 JOIN 是否命中了预期索引。
- 确保每个 ON 右侧字段（如
u1.code、u2.staff_id）都有对应索引 - 如果多次 JOIN 的条件高度相关（比如都基于
id），主键索引足够快，一般无需额外优化 - 极端情况（如 JOIN 5 次以上、表超千万行），考虑先用子查询或 CTE 预聚合，减少 JOIN 次数
IS NOT NULL 就可能让 LEFT JOIN 失效；索引没对齐，性能下降不是线性而是指数级的。这些点在开发时往往只测了“能出数”，上线后才暴露。 
