EXPLAIN 的 rows 列骤增表明 JOIN 顺序不当导致中间结果集膨胀；应优先让高选择性表或小表驱动，右表过滤条件须写入 ON 而非 WHERE，ON 字段需建索引且顺序合理。
EXPLAIN 的 rows 列突然暴涨，就是 JOIN 顺序出问题的信号
数据库优化器确实会重排 JOIN 顺序，但你写的顺序决定了中间结果集的“初始膨胀点”。比如 orders JOIN users JOIN products，若前三张表都无强过滤条件，前两表一连就可能生成几十万行临时结果——第三张表再 JOIN，不是在 10 条数据上操作，而是在 50 万条上做嵌套循环。
用 EXPLAIN 看执行计划时，重点盯紧 rows 列：如果某次 JOIN 前的 rows 值从几千跳到 30 万，那它大概率就是膨胀源头。此时不是索引没建好，而是驱动表选错了。
- 高选择性表优先：带
WHERE status = 'paid'或created_at > '2025-01-01'的表，应尽量放在 JOIN 链最前面 - 小表驱动大表仍是经验法则：比如
categories（20 行）比order_items（千万行）更适合当第一个表 - MySQL 中可用
STRAIGHT_JOIN强制顺序，但必须先跑ANALYZE TABLE更新统计信息，否则可能更慢
LEFT JOIN 右表条件写在 WHERE 里，等于悄悄转成 INNER JOIN
这是线上事故高频点，且直接影响 JOIN 顺序的实际效果。写成 LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'，语义上想保留所有用户，但实际把没订单或订单非 paid 的用户全干掉了——因为 WHERE 是在 JOIN 完成后才执行的，NULL 行被直接过滤。
这不仅改了语义，还让优化器误判：它以为右表可以大胆剪枝，结果发现 o.status 在 WHERE 里，无法下推到 JOIN 前，只能等中间结果出来再扫一遍，rows_examined 翻倍。
- 正确做法是把右表过滤挪进
ON子句：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 检查
EXPLAIN的Extra列：若出现Using where且涉及右表字段，就是危险信号 - 如果业务真需要“左表全量 + 右表按状态匹配”，得确认右表该字段允许 NULL；否则
LEFT JOIN失去意义
三张以上表直接链式 JOIN，优化器容易“懵”
当写 a JOIN b JOIN c JOIN d，尤其某些表之间没有直接外键关系、或存在一对多时，优化器很难判断哪个是安全的驱动表。它可能放弃下推过滤条件，转而走 Block Nested Loop，导致扫描行数指数级增长。
这时候与其硬调顺序，不如主动拆解：把高频聚合或强过滤逻辑提前物化，让后续 JOIN 对象变小。
- 优先用子查询或 CTE 预筛：
(SELECT * FROM orders WHERE status = 'paid')再 JOIN，比全表 JOIN 后加 WHERE 快一个数量级 - 对只查“是否存在”的场景，用
EXISTS替代LEFT JOIN ... IS NOT NULL，语义清晰且通常不生成中间大结果集 - 超大表关联务必加时间范围或 LIMIT 控制输入规模，比如
AND o.created_at >= '2024-01-01'
ON 条件字段没索引，JOIN 顺序再合理也白搭
无论你怎么调表顺序，只要 ON 里的关联字段（尤其是被驱动表那一侧）没索引，数据库大概率 fallback 到全表扫描。比如 LEFT JOIN book ON class.card = book.card，若 book.card 没索引，每次匹配都要扫完整个 book 表。
注意：LEFT JOIN 中，右表是被驱动方，索引必须建在右表的关联字段上；RIGHT JOIN 则相反。建错方向，优化器根本用不上。
- 用
EXPLAIN看type列：出现ALL就代表全表扫描，ref或eq_ref才算走索引 - 复合索引要注意顺序：若
ON a.x = b.x AND b.y = 'val'，索引应为(x, y)，而非(y, x) - 隐式类型转换会让索引失效，比如
user_id是BIGINT，但 ON 里写了CAST('123' AS CHAR)
真正卡住性能的，往往不是 JOIN 本身，而是中间结果集在某个节点失控后，后续所有操作都在处理本不该存在的百万行临时数据。调顺序只是表象，核心是控制每一步的输入规模——这点容易被忽略，但决定成败。
