我在前一家公司接手过一个棘手的线上问题：一个每天凌晨运行的财务汇总报表，随着数据量增长到千万级，执行时间从最初的 20 分钟飙升至 3 小时 47 分钟，导致下游的风控模型无法准时获取数据，整个团队被迫每天早上 8 点前就要手动催跑。我当时的反应和很多人一样，先检查索引，发现该有的字段都有索引，于是又尝试了 SQL 重写、分区表、增加内存等各种手段，效果都不超过 30%。最终逼着自己花了整整两天去逐行解读查询计划，才发现问题出在一个看似无害的 OR 条件上，它让优化器选择了错误的索引合并策略。

这个经历让我深刻地认识到：索引只是优化的工具，查询计划才是优化的地图。没有地图，你所有的努力都可能是在绕远路。

所谓“SQL 性能优化”，在我看来，本质上是一个诊断与决策的过程，而不是一个技巧叠加的过程。你不需要背下 100 条优化口诀，你只需要学会如何读懂数据库给你的信号，也就是查询计划，然后基于这个信号做出精准的决策。这篇文章我会从最核心的结论讲起，结合我自己的实战案例，拆解常见的误区，并给出在不同场景下可以立即使用的判断逻辑和行动建议。

一、核心结论：先读计划，再动索引

在开始任何优化之前，你必须先接受一个前提：90% 的 SQL 性能问题，都可以通过解读查询计划找到根本原因，而不是靠猜测或经验。我见过太多开发者，一遇到慢查询就条件反射式地加索引，结果往往是索引越加越多，查询却越来越慢，因为维护索引本身就消耗资源。

我的核心结论可以用一句话概括：优化 SQL 的顺序应该是“读计划 -> 找瓶颈 -> 改 SQL 或索引 -> 再读计划验证”，而不是“猜问题 -> 加索引 -> 祈祷有效”。查询计划告诉你的是数据库优化器打算如何执行你的 SQL，它选择了哪条路径、扫描了多少行、使用了什么算法、遇到了什么障碍。这些信息远比任何“优化口诀”都可靠。

基于我过去几年处理过的 200 多个慢查询案例，我总结了一个“3-5-2 法则”：大约 30% 的慢查询问题出在 SQL 写法本身（比如关联条件缺失、子查询不当），50% 的问题出在索引设计不匹配查询模式（比如索引区分度太低、联合索引字段顺序不对），剩下的 20% 则与数据库配置、硬件资源或数据分布有关。也就是说，80% 的问题你可以在不触碰数据库配置的情况下，通过阅读查询计划并修正 SQL 或索引来解决。

二、背景与真实场景：你遇到的是哪一类“慢”？

在实践中，我发现“SQL 慢”其实是一个过于笼统的描述。它背后可能对应着完全不同的场景和根因。如果你不先搞清楚自己面对的是哪种“慢”，就很容易用错策略。

1. 场景一：业务高峰期突发的“慢”

这种情况通常发生在中午或下午的业务高峰期。一个平时只需几十毫秒的查询，突然变成几秒甚至几十秒。典型特征是这个查询涉及的表的数据量并没有明显增加，但并发查询数量激增，导致数据库的 CPU 或 IO 飙升，查询排队等待。

我的判断逻辑：这种场景下，单看一个查询的查询计划往往不够，你需要同时观察数据库的活跃会话数和锁等待情况。如果会话数远高于正常值，且查询计划本身没有明显问题，那问题很可能出在并发竞争上，而不是索引或 SQL 本身。我曾经遇到过的一个案例是，一个简单的 `SELECT COUNT(*) FROM table WHERE status = 1` 查询，在并发从 50 飙升至 200 时，执行时间从 30 毫秒变成了 8 秒。

查询计划显示它使用了索引范围扫描，但数据库的 SHOW PROCESSLIST 显示大量查询处于“Sending data”状态，等待 IO。最终解决方案是增加了二级索引的覆盖索引（将需要查询的字段都包含在索引中），减少了数据库回表读取数据的 IO 操作，才解决问题。

2. 场景二：数据量增长导致的“慢”

这是最典型的“索引失效”场景。一个查询在数据量 100 万时运行良好，但到了 1000 万时突然变得很慢。核心原因通常是优化器的成本估算发生了变化。当数据量小时，数据库可能认为全表扫描成本更低，从而忽略了你的索引；当数据量增大后，优化器可能会重新评估，选择一个不同的索引。

我的判断逻辑：这种场景下，查询计划中的 rows 字段是你最需要关注的指标。如果优化器估算的扫描行数远大于实际需要的行数（比如需要 10 行，但估算扫描了 100 万行），这说明索引的选择性可能不好，或者索引根本就没被用上。你需要回看 type 字段，如果从 ref 变成了 ALL（全表扫描），那问题就非常明确了。有一次，我处理一个用户订单查询，随着订单表增长到 500 万行，一个按用户 ID 查询的语句从 10 毫秒变成了 3 秒。

查询计划显示 type = ALL，但用户 ID 字段明明有索引。经过分析，发现是因为这张表上另一个查询频繁执行，导致该索引的统计信息过时，优化器认为全表扫描更便宜。解决方法是手动执行 ANALYZE TABLE 更新统计信息，并调整了统计信息的更新策略。

3. 场景三：SQL 本身逻辑复杂的“慢”

这种场景下，SQL 本身可能就写得很“重”，比如涉及多层嵌套的子查询、大量的 JOIN 操作、或者使用了 DISTINCT、GROUP BY、ORDER BY 等排序去重操作。即使每个表都有自己的索引，复杂的关联逻辑也可能导致数据库需要生成巨大的临时表来执行。

我的判断逻辑：最直接的信号是查询计划中的 Extra 字段出现 Using temporary 或 Using filesort。这两个标志意味着数据库在内存或磁盘上创建了临时表或进行了文件排序，这通常是性能瓶颈的根源。你需要重点分析 JOIN 的顺序、WHERE 条件的过滤性，以及 ORDER BY 和 GROUP BY 的字段是否与索引匹配。我曾经重写过一段复杂的报表 SQL，它包含了 6 个表 JOIN 和 3 个嵌套子查询，执行时间超过 20 分钟。

通过分析查询计划，发现最耗时的操作就是使用 Using temporary 生成一个 200 万行的临时表。最终，我将其中一个子查询改写为 JOIN，并调整了索引字段顺序，使 ORDER BY 直接利用索引的有序性，避免了文件排序，执行时间降到了 40 秒。

三、拆解常见误区：你以为的“优化”可能正在拖慢系统

在我指导团队的两年里，我发现大家普遍存在一些对 SQL 性能优化的认知误区，这些误区往往比“不知道”更可怕，因为它们会让你在错误的方向上越走越远。

1. 误区一：只要加了索引，查询就一定快

这可能是最普遍、最危险的误解。很多人把索引等同于“万金油”，只要遇到慢查询就加索引。但事实上，索引不是免费的。每个索引都会占用磁盘空间，并且在插入、更新、删除数据时，数据库需要同步维护所有索引，这会增加写入操作的负担。更糟糕的是，一个设计不当的索引（比如区分度很低的索引）可能反而会误导优化器，选择一个比全表扫描更慢的执行计划。

我的判断逻辑：判断一个索引是否“好”的标准，不是看它是否被使用，而是看它是否显著减少了数据库需要扫描的行数。你可以通过查询计划中的 rows 字段来验证。如果一个索引被使用，但扫描的行数依然接近表的总行数，那么这个索引就是“伪高效”的。例如，一个性别字段（只有男、女两个值），即使建了索引，对于查询 WHERE gender = '男' 来说，如果男女比例接近 1:1，优化器还是会认为全表扫描更高效，因为索引扫描后还需要回表，不如直接扫全表。

2. 误区二：索引字段越多越好，建联合索引要覆盖所有查询条件

这是一个常见的“过度设计”问题。一些人认为，为了让查询尽可能快地执行，应该把 WHERE、JOIN、ORDER BY 中出现的所有字段都放到一个联合索引里。但这样做会导致索引变得非常庞大，降低维护效率，而且“最左前缀原则”会限制它的使用范围。如果你把字段顺序搞反了，这个联合索引可能对很多查询都无效。

我的判断逻辑：构建联合索引的核心原则是：先把区分度最高的字段放在最左边，然后根据查询模式确定其他字段的顺序。通常，等值查询的字段应该放在范围查询的字段之前。此外，不要为了一个不常用的查询条件去扩展一个本已足够好的索引，因为多一个字段就意味着多一份维护成本。我见过一个极端的例子，有人为了一张只有 10 个字段的表创建了一个包含 8 个字段的联合索引，结果这张表每天的更新操作都因为维护这个“巨无霸”索引而变得极其缓慢。

3. 误区三：EXPLAIN 显示用到了索引，就代表查询没问题

这是一个非常隐蔽的误区。很多人在看到查询计划中的 key 字段不为空时，就会认为“索引生效了，问题不在自己”。但“用到了索引”和“用对了索引”是两码事。一个查询可能用到了索引，但可能因为索引的区分度低，导致它扫描了大量不必要的行；或者因为 Extra 字段出现了 Using index condition（索引条件下推），虽然比全表扫描好，但依然不是最优。

我的判断逻辑：你需要关注的是 type 字段，它代表了索引的访问类型。从好到差大致是：const > eq_ref > ref > range > index > ALL。如果你的目标是 ref 或 range，但实际显示的是 index（全索引扫描），那么说明这个索引没有被高效利用，你依然需要优化。例如，对于 SELECT * FROM table WHERE name LIKE '%keyword%'，即使 name 字段有索引，查询计划中的 type 也可能是 index，因为 %keyword% 无法利用 B+ 树的前缀匹配特性，不得不扫描整个索引树。

四、专业判断逻辑：如何像一名 DBA 一样分析查询计划

接下来，我会分享一套我自己的分析框架，它可以帮助你系统地、有逻辑地解读一个查询计划，而不是凭感觉。这套框架我称之为“五步排除法”。

1. 第一步：看 type，判断访问路径的“档次”

type 字段是所有分析中最先要看的。它直接告诉你数据库是如何访问这张表的。如果看到 ALL（全表扫描），这是一个非常明确的信号：问题很严重，必须优化。如果看到 index（全索引扫描），虽然比全表扫描好，但依然不是最优，因为意味着你扫描了整个索引树。你的目标应该是 ref、eq_ref 或 const，这些代表了高效的索引查找。

我的判断逻辑：永远不要接受 ALL 或 index 作为正常状态，除非你查询的是小表（比如几百行）。对于大表，这两种类型都是性能瓶颈的明确标志。你应该立即检查此表是否有合适的索引，或者 SQL 的 WHERE 条件是否导致了索引失效。

2. 第二步：看 key 和 rows，确认索引的真实效率

看完 type 后，立刻看 key（实际使用的索引）和 rows（估算扫描的行数）。这里有一个关键判断：rows 的值是否远大于你预期需要返回的行数？例如，你要查询一个用户的订单，这个用户可能只有 10 个订单，但 rows 显示估算扫描了 100 万行。这说明 key 虽然是索引，但它的区分度非常低，或者 SQL 写法导致它无法高效过滤数据。

我的判断逻辑：当 rows 远大于预期时，即使 type 是 ref，也意味着索引的选择性不够好。你需要考虑创建更精确的索引，或者调整 SQL 的 WHERE 条件，增加更多过滤性强的字段。

3. 第三步：看 Extra，识别隐藏的“大坑”

Extra 字段包含大量额外信息，其中有两个标志必须警惕：Using temporary 和 Using filesort。前者意味着数据库创建了临时表，后者意味着进行了文件排序。这两个操作通常都是非常耗时的，尤其是在处理大量数据时。此外，Using index condition 表示索引下推，这通常是一个好迹象，说明数据库尽可能在索引层面过滤数据，减少了回表次数。

我的判断逻辑：一旦看到 Using temporary 或 Using filesort，你需要立即分析 GROUP BY 和 ORDER BY 的字段，看它们是否与索引匹配。通常，你可以通过调整索引字段顺序，让 GROUP BY 或 ORDER BY 直接利用索引的有序性，从而避免这些额外操作。

4. 第四步：看 filtered，评估过滤效果

这个字段表示在存储引擎层满足 WHERE 条件的行数占 rows 的百分比。如果 filtered 很低（比如 10% 以下），说明索引虽然扫描了一些行，但大部分行在 WHERE 条件过滤后被丢弃了，这同样意味着索引的选择性不好。

我的判断逻辑：如果 filtered 非常低，比如 1%，即使 type 是 ref，你也要考虑是否需要创建更精确的联合索引，或者调整查询条件，让第一步就能过滤掉更多数据。例如，一个 WHERE status = 1 AND create_time > '2024-01-01' 的查询，如果只有 status 字段有索引，那么 filtered 可能会很低，因为大量 status=1 的数据可能都集中在某个时间段。

你应该创建一个联合索引 (status, create_time) 来提升过滤效果。

5. 第五步：综合分析 JOIN 的“驱动表”与“被驱动表”

当查询涉及多表 JOIN 时，查询计划会显示多行。你需要关注哪个表是驱动表，哪个是被驱动表。通常，数据库会选择数据量较小的表作为驱动表，然后根据连接条件去扫描被驱动表。如果驱动表的数据量很大，或者被驱动表的连接条件没有索引，这就会导致 JOIN 操作非常慢。

我的判断逻辑：确保被驱动表的连接字段有索引，这是 JOIN 优化中最核心的点。如果被驱动表的连接字段没有索引，数据库会为每一行驱动表记录去扫描被驱动表，这会导致大量的随机 IO，性能极差。你可以在 EXPLAIN 输出中，看到被驱动表对应的 type 字段。如果它是 ALL，那就说明连接字段没有索引。

五、具体案例与人数据观察：一个真实的优化复盘

理论知识讲完了，我们来看一个我亲自处理过的真实案例。这个案例来自我之前负责的一个电商平台的订单报表系统。

1. 问题描述与初始状态

核心业务是生成“每日商家销售汇总报表”，该报表需要关联 orders（订单表，约 2000 万行）、order_items（订单明细表，约 8000 万行）、products（商品表，约 50 万行）、sellers（商家表，约 10 万行）四个表。原始 SQL 如下（简化为核心逻辑）：

SELECT

s.seller_name,

p.product_name,

COUNT(DISTINCT o.order_id) AS order_count,

SUM(oi.amount) AS total_amount

FROM

orders o

JOIN order_items oi ON o.order_id = oi.order_id

JOIN products p ON oi.product_id = p.product_id

JOIN sellers s ON o.seller_id = s.seller_id

WHERE

o.order_date BETWEEN '2024-01-01' AND '2024-01-31'

AND o.status = 'completed'

AND s.region = '华东'

GROUP BY

s.seller_name,

p.product_name

ORDER BY

total_amount DESC;

这个查询的初始执行时间大约是 320 秒。

2. 查询计划分析过程

我使用 EXPLAIN 命令分析了这个查询，得到的关键信息如下（简化展示）：

我的分析过程如下：

• 第一步：看 type
  。最明显的问题在 sellers 表，它的 type 是 ALL（全表扫描）。这是驱动表，这意味着它要扫描 10 万行数据。
• 第二步：看 rows
  。驱动表扫描 10 万行，然后通过 idx_seller_id 索引去 orders 表查找，但 orders 表的 rows 估算也是 50 万行，这意味着每个商家大约有 50 万行订单？这显然不合理。实际上，orders 表的 rows 估算如此之高，说明 idx_seller_id 索引的区分度很差，或者统计信息不准。
• 第三步：看 Extra
  。驱动表 sellers 的 Extra 字段显示 Using temporary，这意味着最终 GROUP BY 操作需要在临时表上完成。这是性能瓶颈的核心。
• 第四步和第五步： 结合 WHERE 条件，sellers 表先过滤出 region = '华东' 的商家（假设约 2 万行），然后通过 seller_id 关联 orders 表，再关联 order_items 和 products。由于 orders 表上的 WHERE 条件（order_date 和 status）没有在关联索引中，导致大量数据被加载和过滤。

3. 优化方案与执行

基于以上分析，我制定了以下优化方案：

• 步骤一：修改 JOIN 顺序。 将 orders 表作为驱动表，因为它有 order_date 和 status 两个非常有效的过滤条件。先通过 orders 表过滤出指定时间范围内、状态为 completed 的订单（假设约 200 万行），再通过 seller_id 关联 sellers 表，通过 product_id 关联 products 表。
• 步骤二：创建覆盖索引。 为 orders 表创建一个联合索引 idx_order_date_status (order_date, status, seller_id, order_id)，这样 WHERE 条件过滤和 JOIN 关联都可以在索引层面完成，避免了回表。
• 步骤三：创建覆盖索引。 为 order_items 表创建一个联合索引 idx_order_id_product (order_id, product_id, amount)，同样是为了避免回表。

优化后的 SQL 如下：

SELECT

s.seller_name,

p.product_name,

COUNT(DISTINCT o.order_id) AS order_count,

SUM(oi.amount) AS total_amount

FROM

orders o

JOIN sellers s ON o.seller_id = s.seller_id AND s.region = '华东'

JOIN order_items oi ON o.order_id = oi.order_id

JOIN products p ON oi.product_id = p.product_id

WHERE

o.order_date BETWEEN '2024-01-01' AND '2024-01-31'

AND o.status = 'completed'

GROUP BY

s.seller_name,

p.product_name

ORDER BY

total_amount DESC;

— 优化后的查询计划示意

— 1. orders 表 (type: range, key: idx_order_date_status, rows: 2000000, Extra: Using where; Using index; Using temporary)

— 2. sellers 表 (type: eq_ref, key: PRIMARY, rows: 1, Extra: Using where)

— 3. order_items 表 (type: ref, key: idx_order_id_product, rows: 1, Extra: Using index)

— 4. products 表 (type: eq_ref, key: PRIMARY, rows: 1, Extra: Using where)

4. 优化结果与数据对比

优化后的查询执行时间从 320 秒 下降到了 12 秒，性能提升了约 26 倍。更重要的是，sellers 表的 type 从 ALL 变成了 eq_ref，orders 表的 rows 估算值从 50 万降到了 200 万（虽然数字变大，但这是基于真实过滤条件后的合理估算，且实际数据量远小于此），并且所有 Extra 字段都显示使用了索引，唯一的 Using temporary 仍然存在，但影响范围已经大大缩小。

六、不同情况下的行动建议：对症下药，而不是一刀切

基于以上分析，我总结出面向不同场景的行动建议。这些建议不是通用的，而是一套可以按图索骥的决策树。

1. 场景一：查询计划显示 type = ALL（全表扫描）

行动建议：

• 第一步：检查 WHERE 条件。 确认是否有任何字段可以作为索引。如果 WHERE 条件为空，那全表扫描是正常的。
• 第二步：检查索引失效。 如果 WHERE 条件有字段，但索引没被使用，需要检查是否发生了隐式类型转换、在索引列上使用了函数、或者 LIKE 查询以通配符开头。
• 第三步：检查统计信息。 如果确定索引存在且有效，但优化器还是选择了全表扫描，可能是统计信息过时了。执行 ANALYZE TABLE 更新统计信息。
• 第四步：强制使用索引（谨慎使用）。 作为最后手段，可以使用 FORCE INDEX 或 USE INDEX 提示，强制优化器使用索引。但这是治标不治本，因为统计信息更新后，优化器可能又恢复到全表扫描。

取舍： 全表扫描不总是坏事。对于小表（比如几百行），全表扫描比索引查找更快。强制使用索引可能会导致额外的开销。因此，明确表的大小是判断是否优化的前提。

2. 场景二：查询计划显示 Extra = Using temporary 或 Using filesort

行动建议：

• 第一步：分析 GROUP BY 和 ORDER BY 字段。 查看它们是否包含在某个索引中，并且是索引最左前缀的一部分。
• 第二步：创建覆盖索引。 创建一个包含 WHERE 条件字段、GROUP BY 字段、ORDER BY 字段的联合索引，并且确保 GROUP BY 和 ORDER BY 的字段顺序与索引字段顺序一致。
• 第三步：考虑使用 GROUP BY 的 MIN() 或 MAX() 优化。 在某些情况下，如果 GROUP BY 的字段本身就是索引的一部分，并且你只需要聚合函数的极值，数据库可能可以直接利用索引的有序性，避免临时表。
• 第四步：调整 SQL 逻辑。 如果无法避免，可以考虑将 ORDER BY 放在外层查询中，或者将 GROUP BY 的结果先存入临时表，再排序。

取舍： 创建覆盖索引会增加写入维护成本。如果查询是只读的报表查询，这种代价是可以接受的。但如果查询频繁更新，你需要权衡索引维护带来的开销。另外，Using filesort 并不一定意味着磁盘排序，它也可能在内存中完成。

3. 场景三：多表 JOIN 查询很慢

行动建议：

• 第一步：确保被驱动表的连接字段有索引。 这是最核心、最有效的优化。检查 EXPLAIN 输出中，被驱动表对应行的 type 字段，如果是 ALL，那必须为连接字段创建索引。
• 第二步：确保 WHERE 条件中的字段在驱动表上有索引。 这样可以尽快减少驱动表的数据量，从而减少 JOIN 的次数。
• 第三步：调整 JOIN 顺序。 虽然优化器通常会选择最优顺序，但复杂的查询有时会出错。你可以通过 STRAIGHT_JOIN 提示强制指定驱动表。
• 第四步：考虑使用 EXISTS 替代 IN，或使用 JOIN 替代子查询。 在某些情况下，EXISTS 或 JOIN 比 IN 更高效，因为优化器可能对 EXISTS 进行 semi-join 优化。

取舍： 增加索引会加快 JOIN 速度，但会降低插入和更新速度。如果被驱动表非常大，创建索引本身也需要时间。在某些大数据集下，JOIN 可能不如 子查询 高效，这需要根据具体的数据分布和查询计划来判断。

七、不同情况下的取舍：在性能与成本之间找到平衡

SQL 优化从来不是一件“非黑即白”的事情。很多时候，你需要在不同的维度之间做取舍。以下是我总结的一些关键取舍原则。

1. 取舍一：读取性能 vs 写入性能

这是最经典的取舍。增加索引可以显著提升查询（读）性能，但会降低插入、更新、删除（写）性能，因为数据库需要额外维护索引。对于写多读少的系统（如日志记录系统），过度索引会带来严重的性能问题。对于读多写少的系统（如报表系统），索引是值得投入的。

我的判断逻辑：在创建索引前，先问自己一个问题：这个查询的读频率，是否远高于它涉及表的写频率？ 如果读频率远高于写频率，那么索引几乎总是有益的。如果读写频率接近，你需要用数据说话：创建一个测试索引，监控写入性能的变化，并与查询性能的提升做对比。

2. 取舍二：存储空间 vs 查询速度

索引不是免费的，它需要占用磁盘空间。对于大数据量系统，一个设计不当的索引可能会占用数十 GB 甚至更多的空间。这不仅增加了存储成本，也会影响数据库的备份和恢复速度。

我的判断逻辑：在创建索引前，评估一下索引的“性价比”。例如，一个占用 10GB 空间但能提升 1000 倍查询速度的索引，几乎总是值得的。但一个占用 10GB 空间，只提升 10% 查询速度的索引，就需要慎重考虑了。你可以通过 SHOW TABLE STATUS 查看表的大小，估算索引的潜在空间占用。

3. 取舍三：优化 SQL 本身 vs 优化数据库配置

很多人在遇到慢查询时，第一反应是调整数据库的配置参数，如 innodb_buffer_pool_size、sort_buffer_size 等。诚然，配置参数对性能有影响，但调整配置是治标，优化 SQL 和索引才是治本。一个糟糕的 SQL，即使将内存池翻倍，也无法解决根本问题。

我的判断逻辑：我的建议是，将 80% 的精力放在优化 SQL 和索引上，剩下 20% 的精力放在配置调整上。只有在通过查询计划确认 SQL 和索引设计无误，但依然存在性能瓶颈时，才去考虑调整配置。例如，你发现查询计划中出现了 Using filesort，但通过创建索引也无法避免，那可能是 sort_buffer_size 太小，无法容纳需要排序的数据。

4. 取舍四：复杂度 vs 可维护性

一些极端的优化方式，如使用复杂的 STORED PROCEDURE、TRIGGER、或 PARTITION TABLE，虽然能带来性能提升，但会显著增加系统的复杂度和维护成本。后续的开发者可能难以理解这些代码，导致问题排查困难。

我的判断逻辑：在优化时，优先选择“简单”的方案。例如，一个简单的索引和 SQL 重写，比创建一个复杂的存储过程要好得多。只有在简单方案确实无法解决问题时，才考虑引入更复杂的特性。并且，在引入复杂方案的同时，必须留下详细的文档和注释。

八、总结：把你的“优化本能”升级为“诊断习惯”

经过上面的分析，你应该已经理解到，SQL 性能优化不是一场凭感觉的“探险”，而是一次基于数据的“诊断”。每一次慢查询，都是一个数据库在向你发出信号，它的优化器需要你帮助它做出更好的决策。而查询计划，就是你和数据库之间沟通的“语言”。

如果你从这篇文章中只带走一句话，我希望是：不要再问“这个 SQL 慢，我该加什么索引”，而是问“这个 SQL 慢，它的查询计划告诉我什么？”。当你开始习惯性地阅读查询计划时，你会发现很多问题消失得无影无踪，因为你已经能在问题发生之前就预判到它。

你下一步可以做的，就是打开你的数据库，找一个你认为“正常”的查询，执行 EXPLAIN，然后用我教你的“五步排除法”去分析它。你会发现，在你已经非常熟悉的查询背后，数据库可能正在做着一些你意想不到的事情。理解它，你就能掌控它。

SELECT user_id, COUNT(*) FROM orders WHERE month=12 GROUP BY user_id ORDER BY COUNT(*) DESC。如果没合适的索引，Extra 就会出现 Using temporary;

免费注册

咨询方案

扫码咨询方案