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 次数

别名不是可选项，是语法硬性要求；ON 条件绑错别名，查出来的数据就不可信；WHERE 里一个 IS NOT NULL 就可能让 LEFT JOIN 失效；索引没对齐，性能下降不是线性而是指数级的。这些点在开发时往往只测了“能出数”，上线后才暴露。