EXPLAIN执行计划深度解读:从type到cost,彻底读懂SQL为什么慢

简介: 本期深入解析`EXPLAIN`核心字段:用`key_len`判断索引使用列数,借`filtered`评估回表代价,并详解MySQL 8.0的`EXPLAIN ANALYZE`如何以真实执行数据替代估算,让SQL优化更精准、可验证。

大家好,我是小耶。上周讲了EXPLAIN的3个必看字段,评论区不少朋友说“够用但还想深入”。今天就把它彻底拆开,讲讲key_len怎么判断用了索引的哪几列,filtered如何评估回表代价,以及MySQL 8.0的EXPLAIN ANALYZE为什么比传统EXPLAIN更准。

1 问题背景:为什么只靠type还不够?

在日常优化中,typeALL变成rangeref固然能大幅提升性能,但当多个索引可选时,优化器的选择是否正确?索引用了但扫描行数依然很大怎么办?这些仅靠传统EXPLAIN难以回答。

MySQL 8.0引入了EXPLAIN ANALYZE,可以输出实际执行的成本和时间;FORMAT=JSON则能展示优化器的代价估算。掌握这些,才能真正理解SQL慢在哪里。

2 核心概念:EXPLAIN输出列详解

以下列是按重要性排序的必看项:

  • type​:访问类型。从优到劣:system > const > eq_ref > ref > range > index > ALLALL代表全表扫描,必须优化。
  • possible_keys​:可能用到的索引。若为NULL,说明无可用的索引。
  • key​:实际使用的索引。若为NULL,代表未走索引。
  • key_len​:实际使用的索引字节数。可推算索引中具体用了哪几列(例如utf8mb4每字符4字节,key_len=4表示只用了第一列)。
  • rows​:预估需要扫描的行数。数字越大越慢。但此为估算值,与filtered配合可估算回表行数。
  • filtered​:存储引擎层返回的数据经过WHERE条件过滤后剩余的比例。例如rows=1000filtered=10.00,表示最终大约返回100行。如果filtered很低且索引不包含所有WHERE列,说明需要回表过滤大量数据,可考虑覆盖索引。
  • Extra​:附加信息。常见的有:

    • Using index:覆盖索引,不回表,好。
    • Using index condition:索引下推,较好。
    • Using where:需要回表过滤,通常正常。
    • Using filesort:需要额外排序,应优化。
    • Using temporary:使用临时表,应优化。
  • EXPLAIN ANALYZE​(MySQL 8.0.18+):实际执行查询并输出每个步骤的实际耗时、循环次数、返回行数等,比估算准确。格式示例:
    text

    -> Nested loop inner join  (actual time=0.1..0.2 rows=10 loops=1)
    

    注意:它会真实执行,生产环境慎用。

3 案例解析:从执行计划定位一个真实慢查询

3.1 问题SQL

SELECT * FROM orders WHERE user_id = 123 ORDER BY order_date DESC;

原索引为 (user_id)EXPLAIN结果:

type key rows Extra
ref idx_user_id 5000 Using filesort

rows=5000(该用户有5000条订单),Extra=Using filesort(因为order_date没有索引,需要额外排序)。经验证该查询耗时0.8秒。

3.2 优化过程

添加联合索引 (user_id, order_date)后:

type key rows Extra
ref idx_user_date 5000 (空)

无需filesort,耗时降至0.05秒。这里rows仍为5000,但Extra已无排序,且key_len可判断实际用了两列。

若需进一步优化,可改为覆盖索引 (user_id, order_date, status, amount) 避免回表,Extra会显示Using index

3.3 使用FORMAT=JSON查看代价

EXPLAIN FORMAT=JSON SELECT ...;

输出中的cost_info块展示了read_costeval_costprefix_cost,可比较不同索引的代价估算,帮助理解优化器决策。

4 总结与建议

  • 日常慢查询分析,先看typerows;若type不是ALLrows很大,检查filteredkey_lenExtra中出现Using filesortUsing temporary几乎总是需要优化。
  • MySQL 8.0用户可将EXPLAIN ANALYZE用于测试环境,获取真实执行成本。
  • 掌握这些,就不只是“能看懂”,而是能根据执行计划精准加索引或改写SQL。

理解执行计划是SQL调优的基石。从3个字段到全解读,你的优化能力会上一个台阶。

小耶在手,SQL 不愁。

还有什么想了解的,欢迎留言!小耶一定知无不言言无不尽……我们下次见~

相关文章
|
3月前
|
SQL 关系型数据库 MySQL
一张5000万行的表,加索引从45秒到0.02秒——索引设计你真的会吗
本文实测5000万订单表:无索引查询45秒,加索引后仅0.02秒(提升2250倍)。详解索引原理、建索引时机、联合索引最左前缀、覆盖索引及隐式转换陷阱,干货不啰嗦!
|
3月前
|
SQL 数据库管理 索引
别再滥用IN子查询了!用JOIN改写,从8秒到0.4秒(附优化步骤)
本文揭秘SQL子查询性能陷阱:IN慢因临时表+全量扫描;推荐JOIN改写——利用索引、避免磁盘IO。实测500万订单下,JOIN比IN快20倍!附三步改写法与NULL避坑指南。
|
3月前
|
关系型数据库 MySQL 测试技术
JOIN、IN、EXISTS谁最快?实测三种写法性能差异与执行计划深度剖析
本文用MySQL 8.0实测拆解`IN`/`EXISTS`/`JOIN`子查询性能:从执行计划、半连接优化、临时表开销等底层原理出发,结合10万+100万数据实测(`EXISTS`最快95ms),给出三条选型铁律——告别盲从“最佳实践”,只选最适配业务与数据的写法!
|
2月前
|
SQL 存储 关系型数据库
覆盖索引:让你的查询直接从索引返回,彻底告别回表
覆盖索引是SQL优化中性价比较高的技巧,让查询直接从索引返回所需列,避免回表操作。本文解释覆盖索引的原理,通过EXPLAIN的“Using index”判断是否生效。结合复合索引设计、深分页优化(延迟关联)等场景,给出覆盖索引的使用方法和注意事项。用好覆盖索引,不改SQL逻辑,仅调整索引设计即可显著提升查询性能。
|
3月前
|
SQL 关系型数据库 MySQL
MySQL慢查询诊断实战:从10秒到0.1秒,我的5步排障法
数据库小学妹分享慢查询优化实战:从10秒降至0.08秒!详解「发现→收集→分析→优化→验证」5步排障法,覆盖慢日志配置、EXPLAIN进阶、索引失效场景、JOIN与分页优化等核心技巧,附真实案例与速查表。
|
3月前
|
SQL 关系型数据库 MySQL
MySQL主从复制实战:从原理到读写分离,新手避坑全指南
数据库小学妹带你轻松入门主从复制!✅基于binlog实现主库写、从库读,支撑读写分离与高可用;🛡️保障数据安全(灾备)、提升并发能力;🔧详解三种复制模式、搭建步骤、延迟优化及避坑指南。运维进阶必备!
|
3月前
|
存储 Oracle 关系型数据库
企业级数据库迁移实践:从Oracle到国产数据库的兼容性与实施策略
本文聚焦Oracle向国产数据库的“去O”迁移实战,系统解析兼容性痛点(如存储过程、分页、递归查询等65%~90%适配度)、三类迁移方案选型(全量/增量/并行)及五步实施路径,涵盖评估、结构转换、数据同步、代码适配与性能优化,并推荐KDTS、KStudio等工具链,助力企业安全可控完成异构数据库替换。
|
3月前
|
SQL 缓存 数据库
你还在用LIMIT 1000000,10?献上分页查询优化技巧
本文详解“深分页”陷阱:`LIMIT 1000000,10`为何慢?3种优化方案(游标法、子查询定位、延迟关联)实测提速数十倍,助你零成本提升SQL性能!
|
2月前
|
SQL JavaScript 关系型数据库
SQL改写实战:子查询、CTE、窗口函数性能对比
本文聚焦SQL性能优化,实测对比子查询、CTE与窗口函数在复杂统计、分组排名、递归查询等场景的执行效率。基于MySQL 8.0真实数据(千万级表),揭示窗口函数在“每组取最值”“部门排名”中提速3倍以上,CTE提升可读性与递归能力,而相关子查询易成性能瓶颈。干货满满,避坑必备!
|
3月前
|
SQL 关系型数据库 MySQL
MySQL隐式转换的坑:类型不匹配,索引全废——一个小符号让你慢查询翻车
这篇干货专治MySQL“隐式转换”坑:varchar字段不加引号导致索引失效、全表扫描慢如蜗牛……一个引号之差,性能差万倍!附排查方法、修复案例与避坑口诀,帮你少踩坑、多省命。