MySQL实际JOIN执行顺序由优化器决定，以EXPLAIN的table列从上到下为准，首行为驱动表；应优先选择rows小、有合适索引的表作驱动表，并确保关联字段类型严格一致。
看执行计划里的 table 列顺序，不是 SQL 里写的顺序
navicat 中执行 explain 后显示的 table 列顺序，才是 mysql 实际执行 join 的物理顺序。这个顺序由优化器决定，和你在 sql 中写的 from a join b join c 没有必然关系。如果你发现查询慢，第一件事就是右键 sql → “解释”，然后盯着 table 列从上到下看：哪张表排在最上面，它就是驱动表（即先被全扫描或索引查找的那张）。
常见错误现象：EXPLAIN 显示 type=ALL 出现在第一行的表上，说明这张表被当作了驱动表且没走索引——哪怕它数据量最大、筛选条件最弱。这时优化方向很明确：要么给这张表加索引，要么用 STRAIGHT_JOIN 强制调整顺序（慎用）。
rows 值差异大的表，尽量别当驱动表
驱动表的选择直接影响后续表的扫描行数。rows 列数值越小，说明该表经过 WHERE 条件过滤后剩余行越少，作为驱动表越高效。比如 A 表 rows=10，B 表 rows=100000，理想顺序是 A 驱动 B，而不是反过来。
- 如果
A和B都有等值条件（如WHERE A.status = 'done' AND B.type = 'urgent'），但A的rows明显更小，就说明优化器本该选A当驱动表；若实际执行顺序相反，可能是统计信息过期，可运行ANALYZE TABLE A, B更新。 - 复合索引字段顺序要匹配驱动表的过滤条件。例如驱动表是
orders，常用WHERE user_id = ? AND status = ?，那就建INDEX(user_id, status)，而不是反过来。 - 避免把大表放在
LEFT JOIN的左边还带无索引条件——这等于强制它当驱动表，且无法被过滤。
用 STRAIGHT_JOIN 临时验证顺序影响，但别直接上线
当你怀疑优化器选错了驱动表，可以用 STRAIGHT_JOIN 强制指定顺序来验证效果。例如原语句是 SELECT * FROM B JOIN A ON A.id = B.a_id，但 EXPLAIN 显示 B 在前且 rows 很大，可改成：
SELECT * FROM A STRAIGHT_JOIN B ON A.id = B.a_id
再跑一次 EXPLAIN，对比 rows 总和与 Extra 是否出现 Using join buffer。如果总 rows 显著下降，说明顺序确实关键。
但注意：STRAIGHT_JOIN 是硬编码顺序，一旦表数据分布变化（比如某天 A 表暴涨十倍），它反而会变慢。生产环境应优先通过索引和统计信息让优化器自动选对，而不是依赖这个提示。
JOIN 字段类型不一致会彻底打乱顺序判断
如果两张表关联字段类型不同（比如 A.user_id INT 对 B.uid VARCHAR），MySQL 会隐式转换，导致无法使用索引，优化器失去依据，可能胡乱选驱动表。此时 EXPLAIN 中 key 为空、type=ALL、rows 爆表几乎是必然结果。
检查方法很简单：在“设计表”里分别打开两张表，核对关联字段的类型、长度、字符集是否完全一致。尤其注意 VARCHAR 的长度（VARCHAR(20) 和 VARCHAR(50) 视为不一致）、是否都为 NOT NULL。
修复后务必重新 EXPLAIN —— 类型对齐往往比加索引还管用，因为它是 JOIN 能否走索引的前提。
