决定多表关联性能的关键字段是type、rows、extra；type为all或index表示全表/索引扫描；rows相乘接近实际扫描量；extra含using join buffer说明未走索引、性能风险高。
EXPLAIN 输出中哪些字段直接决定多表关联性能
关键看 type、rows、Extra 这三项。如果任意一个 type 是 ALL 或 index，说明某张表在关联时做了全表扫描或全索引扫描；rows 值不是估算行数，而是 MySQL 认为需要检查的行数，两个表的 rows 相乘接近实际扫描量级；Extra 中出现 Using join buffer (Block Nested Loop) 就意味着没走索引关联，退化成嵌套循环+缓冲区匹配，性能风险极高。
为什么 INNER JOIN 的 EXPLAIN 显示 type=ALL，但加了 WHERE 条件还是慢
常见原因是驱动表选错了。MySQL 会按统计信息自动选择驱动表（即外层循环表），但如果统计信息过期、或 WHERE 条件只作用于被驱动表，优化器可能误判。此时要人工干预：
- 用
ANALYZE TABLE更新统计信息 - 用
STRAIGHT_JOIN强制指定连接顺序，例如SELECT STRAIGHT_JOIN ... FROM t1 JOIN t2 ON ... - 检查被驱动表的
ON字段是否有有效索引，且索引最左前缀必须覆盖关联条件 -
WHERE条件若只写在被驱动表上，无法减少驱动表扫描量，它只是过滤最终结果集
EXPLAIN FORMAT=JSON 比传统格式多出什么关键信息
传统 EXPLAIN 看不到关联顺序的决策依据和代价估算细节。EXPLAIN FORMAT=JSON 会返回 query_cost、used_columns、pushed_condition 和嵌套的 join_execution 结构。特别注意：
-
query_cost是优化器估算的总开销，数值越大越慢，可横向对比不同写法 -
used_columns能确认是否真的用到了你建的联合索引的所有字段 -
pushed_condition表示 WHERE 条件是否下推到存储引擎层执行，没下推意味着更多数据要传到 Server 层再过滤 - 如果
join_execution下出现materialized_from_subquery，说明子查询被物化，需警惕临时表开销
多表 JOIN 时如何快速定位缺失的索引
别只盯着 EXPLAIN 的 key 列是否为 NULL。更有效的方法是结合 SHOW WARNINGS 查看重写后的 SQL：
- 执行
EXPLAIN SELECT ...后立即执行SHOW WARNINGS，能看到优化器是否重写了 JOIN 顺序或合并了条件 - 对每个
ON和WHERE中涉及的字段组合，用SELECT COUNT(*)验证实际选择性，低选择性字段单独建索引意义不大 - 三张及以上表关联时，优先保证驱动表的过滤条件字段 + 每个被驱动表的关联字段构成联合索引，例如
t2(a_id, status)而非仅t2(a_id) - 注意
ORDER BY和LIMIT对执行计划的影响——即使关联本身快，排序没走索引也会拖垮整体响应
关联查询的性能拐点往往不在 SQL 写法本身，而在统计信息准确度、索引覆盖完整性、以及驱动表与被驱动表的数据分布是否匹配。这些没法靠一次 EXPLAIN 看全，得把 EXPLAIN、SHOW WARNINGS、ANALYZE TABLE 和真实 SELECT COUNT(*) 结合着看。
