当前位置：首页 > news >正文

从索引设计到执行计划：一条慢查询的“体检”全流程

news 2026/6/16 22:49:23

大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

慢查询优化，很多人的做法是：看到SQL慢，先猜是不是没索引，加一个试试；不行就再换一个；还不行就改写SQL碰运气。这种做法效率低，而且往往治标不治本。

真正的优化应该是一套“体检”流程：从索引设计是否合理，到执行计划如何解读，再到统计信息是否准确，最后到SQL改写验证——形成一个完整的闭环。今天我就用一条真实的慢查询，把这个流程完整走一遍。

第一步：索引设计——地基没打好，后面全白费

很多慢查询的根源，不是优化器选错了，而是压根没有合适的索引。

设计索引有几个基本原则，这些原则不是背口诀，而是有底层逻辑支撑的。

等值查询的列放左边，范围查询的列放右边。原因是在B+Tree结构中，索引首先按最左列排序，当遇到范围查询（>、<、BETWEEN）时，后续列无法继续使用索引。所以设计复合索引时，要把=的条件放在前面，>、<等范围条件放在后面。
高选择性的列优先。选择性 = 不重复值数量 / 总行数。选择性越高，索引过滤效果越好。比如身份证号的选择性接近1，而性别只有0.5。把高选择性的列放在复合索引前面，能更快缩小扫描范围。
考虑覆盖索引。如果查询需要的所有列都包含在索引中，就不需要回表，Extra会显示Using index。这能减少一半以上的I/O。

假设我们有这样一张订单表，经常执行查询“查询某店铺某状态下，最近一段时间的订单”：

SELECT order_id, amount, create_time FROM orders WHERE shop_id = 123 AND status = 'PAID' AND create_time > '2026-01-01';

根据上述原则，推荐的复合索引是(shop_id, status, create_time)。shop_id和status是等值查询且选择性较好，放在前面；create_time是范围查询，放在最后。同时这个索引覆盖了查询所需的order_id、amount（需要回表）、create_time，部分实现了覆盖。

第二步：执行计划解读——让数据库告诉你问题在哪

索引建好了，但优化器是不是真的用了？这就要看执行计划。

执行上面查询的EXPLAIN，我们可能会看到这样的输出：

type	key	key_len	rows	Extra
ref	idx_shop_status_time	8	23	Using where

逐列解读：

type=ref：用了普通索引，效率良好，不是ALL或index，说明索引生效。
key：实际使用了我们创建的复合索引。
key_len=8：shop_id（4字节）+status（假设4字节），说明只用到了前两列，create_time没有参与索引过滤。这是因为create_time是范围条件，索引在遇到范围后停止匹配，这是正常现象。
rows=23：优化器预估只扫描23行，非常好。
Extra=Using where：需要回表后过滤create_time，但23行回表代价很小。