MySQL三表INNER JOIN必须按外键依赖顺序书写，从主表orders开始，依次JOIN users和products；必须使用表别名避免字段歧义；关联字段需建立索引以防性能断崖；LEFT JOIN的筛选条件须写入ON子句而非WHERE，否则会退化为INNER JOIN。
INNER JOIN 三表关联必须按依赖顺序写
MySQL 不会自动推导表之间的逻辑链路，你写的顺序直接决定执行路径。如果把 products 放在第一个 JOIN 位置，但它的 product_id 只在 orders 中有外键，那就会报 Unknown column 'p.product_id' in 'on clause' —— 因为 p 在当前上下文中还没被引入。
正确做法是：从主业务实体（如 orders）开始，再逐级连它引用的表：
-
orders是核心，它有user_id和product_id两个外键 - 先
JOIN users关联用户信息，用o.user_id = u.id - 再
JOIN products关联商品信息，用o.product_id = p.id
示例：
SELECT o.order_id, u.name, p.product_name FROM orders o INNER JOIN users u ON o.user_id = u.id INNER JOIN products p ON o.product_id = p.id;
别名不光为了省字，更是避免字段歧义
三张表里都可能有 id、name、created_at 这类通用字段。不加别名，SELECT * 会失败，SELECT name 会报 Column 'name' in field list is ambiguous。
实操建议：
- 每张表必须定义简短且一致的别名，比如
o、u、p -
SELECT列、ON条件、WHERE子句中所有字段都带别名前缀 - 别名一旦定义，全程使用，不要混用
users.name和u.name
错误写法：
SELECT order_id, users.name, product_name -- users.name 没问题，但 product_name 缺少别名前缀
性能断崖常发生在中间表没索引
三表 INNER JOIN 的实际执行不是“先连 A+B 得临时表，再连 C”，而是嵌套循环：对 orders 每一行，去 users 找匹配，再对每个匹配结果，去 products 找匹配。如果 users.id 或 products.id 没索引，单次查询就可能扫全表。
检查方式：
- 运行
EXPLAIN看type列是否为const/ref，而不是ALL - 确认
orders.user_id和orders.product_id都建了索引（外键本身不自动建索引） - 如果
products表很大，但只查其中几类商品，考虑在ON后加筛选（如AND p.category = 'electronics'），让优化器提前剪枝
LEFT JOIN 混用时，WHERE 条件会悄悄吃掉左表数据
如果你本意是“查所有订单 + 对应用户（若有）+ 对应商品（若有）”，却写了 LEFT JOIN users 和 LEFT JOIN products，然后在 WHERE 里加了 u.status = 'active'，那结果等价于 INNER JOIN —— 所有 u.status 为 NULL 的订单都会被过滤掉。
真正保左表全量的做法只有两个：
- 把右表的筛选条件写进
ON，比如LEFT JOIN users u ON o.user_id = u.id AND u.status = 'active' - 或者用子查询先筛右表：
LEFT JOIN (SELECT * FROM users WHERE status = 'active') u ON o.user_id = u.id
这个细节在三表混合 INNER 和 LEFT 时最容易翻车，尤其当开发只看局部 SQL 而忽略整体语义时。
