最关键字段是type、key、rows、extra：type表扫描方式（all最差），key显示实际用索引（null即未走索引），rows为预估扫描行数，extra中using filesort或temporary提示排序/分组未走索引。
EXPLAIN 输出里哪些字段最关键
看懂 EXPLAIN 不是比谁字段数多，而是盯住几个直接影响性能的字段：type、key、rows、Extra。其中 type 是扫描方式，从好到差大致是 const ≈ eq_ref > ref > range > index > ALL；ALL 意味着全表扫描，得优先处理。key 显示实际使用的索引，如果为 NULL，说明没走索引（哪怕表上有索引）；rows 是 MySQL 预估扫描行数，不是结果行数，数值越大越危险；Extra 里的 Using filesort 或 Using temporary 是明显信号——排序或分组没走索引，可能触发磁盘临时表。
为什么加了索引，EXPLAIN 还显示 type=ALL
常见原因不是索引没建，而是索引没被选中。比如查询条件用了函数：WHERE YEAR(create_time) = 2024，哪怕 create_time 有索引也失效；或者 LIKE 左模糊：LIKE '%abc'；又或者隐式类型转换：user_id 是 VARCHAR，但写成 WHERE user_id = 123（数字），MySQL 会放弃索引做全表转换。另外，MySQL 认为走索引成本更高时也会跳过——比如表很小、或筛选条件返回大量数据（> ~20% 行数），优化器可能直接选 ALL。
- 检查
WHERE子句是否对索引列做了计算、函数调用或类型不匹配 - 用
SHOW CREATE TABLE确认索引定义和字段类型是否一致 - 强制走索引可加
USE INDEX测试，但别在线上滥用——它绕过优化器判断，可能更慢
EXPLAIN FORMAT=JSON 能看出什么额外信息
EXPLAIN FORMAT=JSON 比传统格式多出执行成本（cost_info）、访问方法细节（access_type）、是否使用索引下推（using_index_condition）等。尤其当看到 "using_index_condition": true，说明 MySQL 在存储引擎层就做了部分 WHERE 过滤（ICP），能显著减少回表次数。而 "filtered": 10.0 表示预估该表条件过滤后剩下 10% 的行——如果这个值极低（比如 0.1），但 rows 很大，说明索引选择性差，可能需要调整索引顺序或补充字段。
- 用
FORMAT=JSON时注意嵌套层级深，重点看顶层query_block和每个table下的cost_info和used_columns - 对比
rows和filtered：若rows是 100000，filtered是 1.0，说明几乎没过滤，索引效率低 - 留意
attached_condition—— 它告诉你哪些条件被下推到了引擎层，哪些还在 Server 层做
联合索引生效的边界在哪
联合索引 (a,b,c) 并不等于三个单列索引。它能高效支持 WHERE a=1、WHERE a=1 AND b=2、WHERE a=1 AND b=2 AND c=3，但 WHERE b=2 或 WHERE b=2 AND c=3 就无法利用最左前缀，通常退化为 index 或 ALL。更隐蔽的是范围查询断点：WHERE a=1 AND b>2 AND c=3 中，c 实际上无法走索引——因为 b>2 是范围，后续字段失效。
- 等值条件（
=、IN）可连续使用最左前缀，范围条件（>、、<code>BETWEEN）之后的字段不再用于索引查找 -
ORDER BY字段必须严格匹配索引最左连续部分，且方向一致（不能混合ASC/DESC） - 用
EXPLAIN配合SELECT *和SELECT a,b对比：后者若能触发Using index，说明走了覆盖索引，避免回表
真正难的不是看懂 EXPLAIN，而是把输出和索引设计、查询写法、数据分布三者串起来——同一句 SQL，在不同数据量、不同数据倾斜度下，type 和 rows 可能天差地别。别只盯着一次输出做优化，要结合 SHOW INDEX、真实 SELECT COUNT(*) 和慢查询日志交叉验证。
