MySQL 覆盖索引减少回表读取的实现方法

我排查 MySQL 列表接口的慢查询时，最先改掉的往往不是 SQL，而是查询投影：接口只要订单号、状态和更新时间，却写成了 SELECT *。更合适的做法是围绕真实的 WHERE、排序条件和返回列设计联合索引，让索引叶子节点直接提供查询需要的值。这样优化器有机会只扫描索引树，减少根据主键回到聚簇数据页取整行的次数。

先把查询投影变成可覆盖的索引候选

覆盖关系由具体 SQL 决定。假设订单列表只取三列，并按租户、状态筛选后按更新时间倒序：

-- 列表接口只返回轻量字段，先明确查询投影。
SELECT order_no, status, updated_at
FROM orders
WHERE tenant_id = 42 AND status = 'paid'
ORDER BY updated_at DESC
LIMIT 50;

这条语句的候选列至少包括 tenant_id、status、updated_at、order_no。一个可讨论的索引是 (tenant_id, status, updated_at, order_no)。前两列承担常用等值过滤，updated_at服务排序，最后的订单号用于直接返回。若把 SELECT * 留在接口里，索引就必须覆盖所有被读取的列，通常会变宽到不值得维护。

按过滤、排序和返回列组合联合索引

实际设计时我会把它当成发布流水线：先确认查询入口，再给出候选 DDL，最后才让执行计划作为门禁。联合索引的左侧顺序不能只看“哪些字段都出现过”，还要看过滤选择性、排序需求和同一张表上的其他查询。对固定租户场景，tenant_id 和 status 适合放在前面；如果状态区分度极低，仍应结合真实数据分布判断，而不是套用固定口诀。

-- 候选索引覆盖过滤、排序和列表返回列；名称保留业务意图。
CREATE INDEX idx_orders_tenant_status_updated_no
    ON orders (tenant_id, status, updated_at, order_no);

-- 只取必要列，避免 SELECT * 扩大覆盖范围和索引体积。
SELECT order_no, status, updated_at
FROM orders
WHERE tenant_id = 42 AND status = 'paid'
ORDER BY updated_at DESC
LIMIT 50;

这里的“覆盖”不等于“永远最快”。索引里的每个额外列都会增加存储、缓存和写入维护成本；大尺寸文本、低频返回列不应为了某一条列表查询直接加入。对读多写少的列表表，适度扩展投影可能划算；对高频写入表，更应该先比较查询收益与插入、更新代价。

用 EXPLAIN 验收是否真的减少回表

创建索引后不能只看 DDL 成功。用同样的参数检查执行计划：

-- 用执行计划观察优化器选择的索引和预计扫描行数。
EXPLAIN
SELECT order_no, status, updated_at
FROM orders
WHERE tenant_id = 42 AND status = 'paid'
ORDER BY updated_at DESC
LIMIT 50;

如果 key 为空，先检查条件是否可使用索引、统计信息是否过期，以及候选索引是否真的比其他路径更便宜。InnoDB 表可以在数据分布变化后执行 ANALYZE TABLE orders 更新统计信息，再重新观察计划。不要一看到未选中就立刻使用 FORCE INDEX，否则数据分布变化后可能把优化器锁在更差的路径上。

给索引增加可回滚的门禁

覆盖索引的验收标准至少包括三层：查询只选必要列；执行计划选中预期索引并出现合理的 Using index；线上写入延迟和索引空间没有超过预算。若查询还要读取金额、收货地址等未进入索引的字段，回表是业务需求，不是索引失败。更稳妥的发布记录应保存原 SQL、候选索引、EXPLAIN 变化和撤销 DDL，先在相同数据分布的环境验证，再逐步放量。

相关问题

覆盖索引是不是必须包含整张表的所有列

不是。它只需要覆盖当前查询实际读取的列，包括过滤、排序、连接和结果投影所需字段；换一条 SQL，覆盖关系可能就不同。

出现 Using index 就代表查询一定很快吗

不一定。它只表示可以从索引直接取得所需列，还要结合扫描行数、排序、并发、缓存命中和返回数据量判断整体成本。

索引没被选中时先做什么

先核对 SQL 条件、左侧列顺序和统计信息，再比较实际执行计划；必要时用 ANALYZE TABLE 更新统计信息，最后才评估索引提示。

我更愿意把覆盖索引当成一次有边界的查询改造：缩小投影、组合必要列、用 EXPLAIN 验收，再把写入成本纳入发布门禁。它适合稳定的高频读取路径，不适合给每个查询都堆一套宽索引。