EXPLAIN是数据库性能优化的基石，它提供了一个透视镜，让我们能深入了解SQL查询在数据库内部是如何被执行的。这不仅仅是看一眼执行计划那么简单，更重要的是理解数据库为什么会选择这条路径，以及这条路径可能带来的性能影响。通过它，我们能提前发现潜在的性能瓶颈，而不是等到线上出现问题才手忙脚乱。 解决方案
要使用
EXPLAIN进行SQL性能分析，最直接的方式就是在你的
SELECT、
INSERT、
UPDATE或
DELETE语句前加上
EXPLAIN关键字。数据库会返回一个执行计划，这个计划详细描述了查询优化器打算如何处理你的SQL语句，包括访问哪些表、使用哪些索引、以何种顺序连接表、以及如何处理排序和分组等操作。
例如，对于一个简单的查询：
EXPLAIN SELECT * FROM users WHERE age > 30 AND city = 'New York';
执行后，你会得到一个表格或JSON格式的结果，里面包含了多行信息，每一行代表一个操作步骤。初次接触可能会觉得有些晦涩，但随着你对各个字段的理解加深，你会发现它就像一张藏宝图，指引你找到性能优化的方向。我的经验是，不要指望一次
EXPLAIN就能解决所有问题，它更像是一个迭代的过程：分析计划，提出假设，修改SQL或索引，再
EXPLAIN，直到你满意为止。 如何解读Explain输出中的关键指标？
理解
EXPLAIN的输出是优化SQL性能的关键一步。它不是简单的读表，而是要理解每个字段背后的含义，以及它们如何相互关联。
首先，
id字段标识了查询的各个操作块，对于复杂查询（如包含子查询或UNION），它能帮助你理解执行顺序。
select_type则告诉你这个操作块的类型，比如
SIMPLE（简单查询）、
PRIMARY（最外层查询）、
SUBQUERY（子查询）或
DERIVED（派生表，通常是子查询的结果）。这些类型能让你对查询的整体结构有个初步判断。
接下来，
table字段明确了当前操作涉及的表。最核心的指标之一是
type，它描述了数据库如何访问表中的行。
system
、const
、eq_ref
、ref
：这些都是非常高效的访问类型，通常意味着通过主键或唯一索引直接定位到少数几行，或者通过非唯一索引进行等值匹配。看到这些，你通常可以松一口气。range
：表示索引范围扫描，比如WHERE id > 100 AND id < 200
。效率也不错，但不如前几种精确。index
：全索引扫描。虽然比全表扫描快，因为它避免了访问数据行，但仍然需要读取整个索引。如果索引很大，这也会成为瓶颈。ALL
：这是最需要警惕的，意味着全表扫描。数据库不得不遍历表中的所有行来找到匹配项。这几乎总是性能问题的根源，尤其是在大表上。
possible_keys列出了优化器可能选择的索引，而
key则是它最终决定使用的索引。如果
key为
NULL，但
possible_keys不为空，那说明优化器认为现有索引不适合当前查询，或者查询条件没有充分利用到索引。
key_len则显示了优化器实际使用了索引的多少字节，对于复合索引，这能帮助你判断索引的前缀是否被有效利用。
PIA
全面的AI聚合平台，一站式访问所有顶级AI模型
226
查看详情
rows字段是一个估计值，表示数据库认为它需要检查的行数。这个数字越高，查询的效率通常越低。结合
type字段，如果
type是
ALL且
rows很高，那性能问题几乎是板上钉钉了。
filtered表示通过表条件过滤后剩余的行数百分比。
最后，也是最能揭示潜在问题的，是
Extra字段。
Using filesort
：表明数据库需要对结果进行排序，但无法通过索引完成，需要在内存或磁盘上进行额外排序。这通常是性能杀手。Using temporary
：数据库需要创建一个临时表来处理查询，通常发生在复杂的GROUP BY
、DISTINCT
或UNION
操作中。临时表的操作会消耗大量I/O和CPU资源。Using index
：这是个好消息，意味着查询所需的所有列都包含在索引中（覆盖索引），数据库无需访问实际的数据行，直接从索引中获取结果。Using where
：表明数据库在存储引擎层对数据进行了过滤，这本身不一定是坏事，但如果与type: ALL
结合，就意味着全表扫描后再过滤，效率低下。Using index condition
(MySQL 5.6+): 表示索引条件下推优化，数据库在存储引擎层就对索引进行条件过滤，减少了回表次数。
EXPLAIN就像一个X光片，能清晰地展示SQL查询的“骨骼”问题。最常见的性能瓶颈，往往就藏在那些不起眼的
type和
Extra字段里。
1. 全表扫描 (
type: ALL) 这是最显眼、也最致命的瓶颈。当
EXPLAIN显示
type为
ALL时，意味着数据库不得不逐行检查表中的所有数据来找到匹配项。在大表上，这会造成巨大的I/O开销。
-
为什么发生？ 最常见的原因是
WHERE
子句、JOIN
条件、ORDER BY
或GROUP BY
中涉及的列没有合适的索引。或者，即使有索引，但在查询中对索引列使用了函数（如WHERE YEAR(create_time) = 2023
），导致索引失效。有时，数据分布不均匀也会让优化器放弃索引，比如WHERE status = 'active'
，如果90%的记录都是'active'，优化器可能觉得全表扫描更快。 -
如何优化？ 核心是创建并有效利用索引。为
WHERE
、JOIN
、ORDER BY
、GROUP BY
中频繁使用的列创建B-tree索引。避免在索引列上使用函数。确保查询条件的数据类型与索引列的数据类型一致。对于复合索引，确保查询条件能命中索引的最左前缀。
2. 额外排序 (
Extra: Using filesort) 当查询需要对结果进行排序（
ORDER BY）或分组（
GROUP BY），但没有合适的索引支持时，数据库就会在内存或磁盘上进行额外的排序操作。这通常非常耗时。
-
为什么发生？ 索引的列顺序与
ORDER BY
或GROUP BY
的列顺序不匹配，或者索引未能覆盖所有排序/分组的列。例如，你有一个(col1, col2)
的复合索引，但你ORDER BY col2
，索引就无法直接用于排序。 -
如何优化？ 考虑创建覆盖
ORDER BY
或GROUP BY
列的索引，并且索引列的顺序要与排序/分组的顺序一致。如果排序方向（ASC/DESC）也一致，效果会更好。有时候，调整查询语句，比如先过滤再排序，也能减少需要排序的数据量。
3. 使用临时表 (
Extra: Using temporary) 数据库在执行某些复杂查询时，需要创建临时表来存储中间结果。这在
DISTINCT、
UNION、复杂的
GROUP BY或子查询中很常见。临时表的创建、写入和读取都会带来性能损耗。
- 为什么发生？ 通常是由于复杂的聚合操作、需要去重的操作或者子查询无法被优化器有效合并。
-
如何优化？ 审查查询逻辑，看是否可以简化。对于
UNION
，如果确定没有重复数据，可以使用UNION ALL
来避免去重操作。确保GROUP BY
和DISTINCT
涉及的列有合适的索引支持，有时索引可以帮助数据库避免创建临时表。
4. 索引选择不佳或未使用 (
key为NULL或
key与
possible_keys不符) 即使你创建了索引，优化器也可能因为各种原因选择不使用它，或者使用了不够高效的索引。
- 为什么发生？ 数据库的统计信息可能过时，导致优化器对数据分布的判断失误。或者，查询条件不够精确，导致索引选择性太差（比如索引列的值重复率很高）。
-
如何优化？ 定期更新表的统计信息（如MySQL的
ANALYZE TABLE
或PostgreSQL的VACUUM ANALYZE
）。调整查询条件，使其更具选择性。对于复合索引，确保查询条件能充分利用到索引的前缀。在极少数情况下，如果确定优化器做出了错误选择，可以考虑使用FORCE INDEX
（但要慎用，因为它可能在数据分布变化后反而导致性能下降）。
仅仅是
EXPLAIN的输出，有时候还不足以让我们完全理解SQL的性能全貌。特别是在面对复杂的生产环境问题时，我们需要更深入的工具和方法。
1.
EXPLAIN ANALYZE（PostgreSQL 和 MySQL 8.0+） 这是我个人在生产环境中诊断性能问题时最常用的“大杀器”。与普通的
EXPLAIN只展示计划不同，
EXPLAIN ANALYZE会实际执行查询，然后返回真实的执行时间、实际处理的行数以及每个操作的开销。这能帮助我们验证优化器的估计是否准确，并精确找出时间究竟消耗在哪里。
例如，在PostgreSQL中：
EXPLAIN ANALYZE SELECT * FROM users WHERE age > 30 AND city = 'New York';输出会包含
actual time（实际耗时）和
rows（实际返回行数），以及
loops（执行次数）。通过对比
EXPLAIN的估计值和
EXPLAIN ANALYZE的实际值，我们可以判断优化器是否因为统计信息不准确而做出了错误的决策。如果估计行数与实际行数相差悬殊，那往往是统计信息过时或者数据分布异常的信号。
2. 可视化Explain工具 很多现代的数据库客户端工具，比如DataGrip、DBeaver、MySQL Workbench，都提供了图形化的
EXPLAIN输出。这些工具能将复杂的文本输出转化为直观的流程图，用颜色和箭头清晰地展示数据流向、操作顺序和每个步骤的成本。对于包含多个JOIN和子查询的复杂语句，可视化工具能极大地降低理解门槛，让你一眼看出哪些操作是瓶名颈。
3. 覆盖索引（Covering Index）策略 前面提到过
Extra: Using index是个好兆头。这就是覆盖索引的体现。一个覆盖索引是指，一个索引包含了查询所需的所有列，而不仅仅是
WHERE子句中的列。这意味着数据库可以直接从索引中获取所有需要的数据，无需再回表访问实际的数据行。这能显著减少I/O操作，尤其是在查询大量数据时。
例如，如果你经常查询
SELECT name, email FROM users WHERE city = 'New York';一个在
city列上创建的普通索引只能加速
WHERE条件，但数据库仍需回表获取
name和
(city, name, email)就可以作为覆盖索引，直接从索引中返回所有数据。
4. 复合索引的列顺序 复合索引的列顺序至关重要。例如，对于索引
(col1, col2, col3)，它能有效地支持以下查询：
WHERE col1 = ?
WHERE col1 = ? AND col2 = ?
WHERE col1 = ? AND col2 = ? AND col3 = ?
ORDER BY col1, col2
但它可能无法有效支持WHERE col2 = ?
或ORDER BY col2, col1
这样的查询，因为它没有命中索引的最左前缀。在设计复合索引时，应该把选择性最高的列放在前面，或者将最常用于等值查询的列放在前面。
5. 数据库参数与配置 有时，性能问题不完全是SQL或索引的问题，也可能是数据库本身的配置不当。例如，MySQL的
join_buffer_size、
sort_buffer_size、
tmp_table_size等参数，或者PostgreSQL的
work_mem、
shared_buffers等，都可能影响到
EXPLAIN中显示的
Using temporary或
Using filesort操作的性能。适当地调整这些参数，可以为数据库提供更多的内存资源，从而提升这些操作的效率。但这需要对数据库有深入的理解，并且要谨慎操作，避免过度分配资源。
6. 慢查询日志与性能监控工具
EXPLAIN是针对单个查询的深度分析，但要了解整个系统的性能瓶颈，你还需要慢查询日志和性能监控工具。慢查询日志会记录下执行时间超过阈值的SQL语句，这能帮助你快速发现哪些查询是导致系统整体性能下降的“罪魁祸首”。结合
EXPLAIN对这些慢查询进行分析，就能形成一个完整的优化闭环。而像Prometheus、Grafana、Percona Monitoring and Management (PMM) 等工具则能提供实时的数据库性能指标，帮助你发现趋势和异常。
深入分析SQL性能是一个持续学习和实践的过程。
EXPLAIN只是起点，但它为你打开了一扇门，让你能看到数据库内部的秘密。结合其他工具和对数据库原理的理解，你就能成为一个真正的SQL性能调优大师。
以上就是如何使用Explain执行计划深度分析SQL性能？的详细内容，更多请关注知识资源分享宝库其它相关文章！
相关标签： mysql js json 工具 ai 钉钉 sql语句 为什么 red sql mysql json 数据类型 NULL select const union using delete table postgresql 数据库 性能优化 prometheus grafana 大家都在看： MySQL内存使用过高（OOM）的诊断与优化配置 MySQL与NoSQL的融合：探索MySQL Document Store的应用 如何通过canal等工具实现MySQL到其他数据源的实时同步？ 使用Debezium进行MySQL变更数据捕获（CDC）实战 如何设计和优化MySQL中的大表分页查询方案
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。