执行计划中join顺序异常可直接通过explain输出的表访问顺序和type字段判断：第一行为驱动表，后续为被驱动表；若rows远超预期、type=all或出现using join buffer，说明优化器选错驱动表。
怎么看执行计划里JOIN顺序是否异常
直接看 EXPLAIN 输出中表的访问顺序和 type 字段。MySQL 的执行计划默认从上到下表示驱动表顺序：第一行是驱动表，后续每行是被驱动表。如果 rows 列数值远超预期（比如主表只有 1000 行，但第二行显示 rows=500000），大概率是优化器选错了驱动表，导致大表被全扫。
常见异常信号：
-
type=ALL出现在本该走索引的被驱动表上 - 执行计划里出现
Using join buffer (Block Nested Loop)，说明没走索引，退化成内存嵌套循环 - 多表 JOIN 时，小维表（如
products）排在后面，而大事实表（如sales）排在前面且没加有效过滤条件
为什么优化器会选错JOIN顺序
根本原因是统计信息不准或条件选择性误判。比如 WHERE sales.created_at > '2024-01-01' 看似能大幅过滤，但若该字段没有索引，优化器无法准确估算返回行数，就可能放弃用它当驱动条件，转而选一个“看起来更小”但实际不带过滤的表（如 customers）当驱动表。
影响判断的关键点：
- 被驱动表的
JOIN字段没索引 → 无法快速定位，被迫全表扫描 - 驱动表的
WHERE条件没走索引（如函数、类型转换）→ 优化器低估过滤效果 - 表的
cardinality统计过期（ANALYZE TABLE没跑过）→ 优化器以为某表只有 100 行，实际有 100 万
怎么手动验证和修正JOIN顺序
别依赖优化器自动选，先用 STRAIGHT_JOIN 强制顺序验证。把最确定能过滤出少量数据的表放在最前，其余按关联紧密度+索引覆盖程度排列。
示例：
SELECT STRAIGHT_JOIN c.name, p.title, SUM(s.amount) FROM sales s JOIN customers c ON s.customer_id = c.id JOIN products p ON s.product_id = p.id WHERE s.created_at >= '2026-09-01';
这句强制 sales 当驱动表。如果加上 created_at 索引后性能明显提升，就坐实了原执行计划的顺序错误。
上线前必须删掉 STRAIGHT_JOIN，改用建对索引来引导优化器——比如给 sales(created_at, customer_id, product_id) 建联合索引，让驱动和连接都走索引。
容易被忽略的陷阱：JOIN顺序和锁范围强相关
执行计划里驱动表变了，加锁行为也跟着变。比如 UPDATE orders o JOIN users u ON o.user_id = u.id，若优化器选 users 当驱动表，就会先锁一批用户行，再根据 user_id 去锁订单；反过来，orders 驱动则先锁订单再锁用户。两者在高并发下死锁概率完全不同。
所以排查 JOIN 顺序异常时，不能只看 EXPLAIN 的 rows，还得结合 INFORMATION_SCHEMA.INNODB_TRX 查当前事务锁了哪些表的哪些行——顺序不对，锁就乱。
