MySQL优化器按成本选择JOIN实际执行顺序，真正顺序以EXPLAIN的table列为准；LEFT JOIN右表过滤条件必须写在ON中，否则退化为INNER JOIN；多表JOIN需确保ON条件完整且字段有索引，避免笛卡尔积。
MySQL 优化器决定 JOIN 实际执行顺序
你写的 FROM a JOIN b JOIN c 不代表数据库真按这个顺序执行。MySQL 用基于成本的优化器，会估算不同连接路径的代价（比如扫描行数、IO、内存占用），选它认为“最省”的那个。真正执行顺序得看 EXPLAIN 输出的 table 列从上到下的排列——那才是物理执行链路。
常见误区是调换表书写顺序就想“让小表先查”，但优化器可能完全无视它。除非你加 STRAIGHT_JOIN（仅限 INNER JOIN），否则别指望靠写法控制顺序。
-
EXPLAIN中type是const或ref的表，大概率是驱动表 - 如果发现大表被当驱动表且
type = ALL，说明优化器没选对，得检查索引或统计信息 - 用
EXPLAIN FORMAT=TREE（MySQL 8.0+）能更直观看到嵌套结构和连接算法（NLJ / BKA / Hash Join）
LEFT JOIN 的 ON 条件不能挪到 WHERE
这是线上事故高发点。LEFT JOIN b ON a.id = b.a_id WHERE b.status = 'paid' 看似只是加个筛选，实际会让所有 b.status 为 NULL 的行被干掉——LEFT JOIN 就退化成 INNER JOIN 了。
因为 ON 是在关联过程中起作用：匹配时就带上 b.status = 'paid'，没匹配上的 b 字段仍是 NULL；而 WHERE 是关联完才过滤，NULL = 'paid' 为 false，整行被剔除。
- 右表的等值过滤条件（如
status、is_deleted）必须写进ON子句 -
EXPLAIN的Extra列若出现Using where且涉及右表字段，就是危险信号 - 要保留左表全部记录 + 只取右表特定状态，必须写成：
LEFT JOIN b ON a.id = b.a_id AND b.status = 'paid'
三张以上 JOIN 容易触发笛卡尔积
不是表越多越慢，而是漏写或错写 ON 条件时，数据库找不到约束关系，就会默认做全组合——A(1000) × B(1000) × C(1000) 就是 10 亿行。
典型错误是链式写法：A JOIN B ON ... JOIN C ON B.id = C.b_id，但 B 其实没和 A 正确关联上，C 就彻底失联。
- 每层
JOIN的ON至少一边必须来自已声明的表（或别名） - 用别名明确依赖关系，比如
orders o JOIN users u ON o.user_id = u.id JOIN items i ON o.item_id = i.id - 复杂逻辑优先拆成 CTE 或子查询，例如先聚合用户最新订单 ID，再关联详情，避免中间结果爆炸
索引没打在 ON 字段上，顺序再优也白搭
优化器再聪明，也救不了没索引的 ON 字段。比如 A.user_id = B.id，如果 B.id 没索引，B 表就得被扫几十次（嵌套循环下），性能直接崩。
复合索引要注意顺序：等值条件放最左（status），连接字段放中间（a_id），范围条件放最后（ctime）。别在 ON 里写 YEAR(t.create_time) = 2024，函数会让索引失效。
- 外键列不等于自动有索引，必须手动确认并创建
- 字段类型要严格一致（
INTvsBIGINT、VARCHAR(50)vsVARCHAR(100)），否则索引可能无法命中 - 定期执行
ANALYZE TABLE，尤其数据批量变更后，否则优化器用过期统计信息选错计划
EXPLAIN 里，而不是 SQL 写法里；LEFT JOIN 的右表条件放错位置，结果就全偏了；三张表以上，别硬连，先想清楚哪张该当驱动表、哪张该提前过滤——这些细节比语法本身更容易出问题。 
