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

本文涉及的产品
云数据库 PolarDB MySQL 版,列存表分析加速 8核16GB
RDS Agent(兼容OpenClaw),2核4GB
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
简介: 本期深入解析`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 不愁。

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

相关文章
|
1月前
|
SQL 关系型数据库 MySQL
一张5000万行的表,加索引从45秒到0.02秒——索引设计你真的会吗
本文实测5000万订单表:无索引查询45秒,加索引后仅0.02秒(提升2250倍)。详解索引原理、建索引时机、联合索引最左前缀、覆盖索引及隐式转换陷阱,干货不啰嗦!
|
21天前
|
关系型数据库 MySQL 测试技术
JOIN、IN、EXISTS谁最快?实测三种写法性能差异与执行计划深度剖析
本文用MySQL 8.0实测拆解`IN`/`EXISTS`/`JOIN`子查询性能:从执行计划、半连接优化、临时表开销等底层原理出发,结合10万+100万数据实测(`EXISTS`最快95ms),给出三条选型铁律——告别盲从“最佳实践”,只选最适配业务与数据的写法!
|
21天前
|
SQL 关系型数据库 MySQL
批量操作进阶:百万行级数据导入的性能极限
本文分享百万行数据导入四大进阶技巧:分区表减少锁竞争、禁用索引加速写入、并行LOAD DATA榨干多核性能、金仓kdb_load专用工具再提速。实测100万行最快<1秒,助你从分钟级跃升秒级!
|
22天前
|
SQL 关系型数据库 MySQL
写出高效SQL的3个肌肉记忆:从新手到老手的习惯养成
本文总结3个实战派SQL“肌肉记忆”:①WHERE条件中索引字段不加工(禁函数/运算/隐式转换);②存在性检查优先用EXISTS而非IN或JOIN+DISTINCT;③分页用游标、批量操作限流1000行、修改前先SELECT验证。全是踩坑提炼的稳产技巧!
|
25天前
|
存储 Oracle 关系型数据库
企业级数据库迁移实践:从Oracle到国产数据库的兼容性与实施策略
本文聚焦Oracle向国产数据库的“去O”迁移实战,系统解析兼容性痛点(如存储过程、分页、递归查询等65%~90%适配度)、三类迁移方案选型(全量/增量/并行)及五步实施路径,涵盖评估、结构转换、数据同步、代码适配与性能优化,并推荐KDTS、KStudio等工具链,助力企业安全可控完成异构数据库替换。
|
26天前
|
JSON API 数据格式
🚀 RESTful API 接口规范详解:构建高效、可扩展的 Web 服务(附 Python 源码)
本文深度解析RESTful API核心设计原则(资源化、无状态、统一接口等),详解URL规范、HTTP方法语义、状态码使用、响应格式及版本管理,并附可直接运行的Flask实战代码,助你构建专业、可扩展的Web服务。
|
2月前
|
SQL 数据库 数据库管理
从运营到DBA,我用了这3个“偷懒”方法学SQL
用运营人思维教小白轻松学SQL:①把SQL当Excel对话,理解SELECT/FROM/WHERE;②建“报错翻译本”,快速定位解决错误;③用“填空题法”抄改练,复用模板上手。不求完美,先跑通、看懂、不崩溃!
从运营到DBA,我用了这3个“偷懒”方法学SQL
|
2月前
|
SQL NoSQL BI
运营转DBA:我终于知道数据库不是Excel了
小耶分享数据库入门干货:零基础也能懂!对比Excel,解析数据库高效查数、并发处理、数据安全等核心优势;手把手教SELECT/WHERE/JOIN三招入门;避坑提醒——DELETE前先SELECT。转行不难,SQL即问数据的语言!
运营转DBA:我终于知道数据库不是Excel了
|
25天前
|
SQL 关系型数据库 MySQL
批量操作性能飙升:从30秒到1秒的三种实战方法
业务系统中经常需要批量导入或更新大量数据(如Excel上传、定时同步)。许多开发人员采用循环单条执行的方式,导致1万条数据耗时30秒以上,严重影响用户体验。本文从数据库IO、事务开销、锁竞争三个角度分析单条操作的性能瓶颈,并给出三种优化方案:批量INSERT、LOAD DATA文件导入、批量UPDATE用临时表。每种方案均附实测数据对比与适用场景说明,帮助读者在1万\~100万行级别批量操作中选择最优策略。
|
1月前
|
SQL 人工智能 数据库
模型都卷成麻花了,你还在用老办法管数据库?
本文聚焦大模型爆发下DBA新挑战:AI Agent带来的动态查询压力、向量检索成标配、NL2SQL重塑取数流程。倡导“懂数据+懂业务+懂AI”的复合能力转型。

热门文章

最新文章