SQL 的覆盖索引（Covering Index）是一类”查询所需的全部列都在这棵索引里”的非聚集索引。当它成立时，数据库只需扫描索引页就能返回结果，根本不碰表的数据页或聚集索引，从而消除”回表”（Key Lookup / Bookmark Lookup）带来的随机 IO。据 Microsoft Learn 的索引设计指南定义，覆盖索引是”一种能满足查询全部数据访问、无需访问基表的非聚集索引”。覆盖索引不是新建一种索引类型，而是对现有非聚集索引的精心设计——把过滤/排序列放在键里、把其他 SELECT 列用 INCLUDE 放进叶子节点，让 EXPLAIN 出现 Using index（MySQL）或 Index Only Scan（PostgreSQL）即为命中。
一、为什么普通索引要回表
非聚集索引的叶子节点只存”索引键 + 行定位符”（指向聚集索引键或堆行地址）。当查询还需要索引外的列时，引擎必须用定位符再跳回数据页取那些列，这一步就叫回表。据 cnblogs 的覆盖索引原理解析，普通索引流程是”先通过索引找到主键 → 再回表查完整数据行”，当命中行数大时，回表产生大量随机 IO，性能随之下降。SQLServerCentral 的实测更直观：一个原本靠索引 seek 的查询，99% 的耗时都花在 Key Lookup 回表上，仅给索引补一个 INCLUDE 列做成覆盖索引，速度提升约 184 倍。
二、覆盖索引的本质：索引里自带答案
覆盖索引让”查询需要的列”同时出现在索引的键列或非键列（INCLUDE）中，引擎读完索引即可返回，流程从”索引 + 回表”变成”仅索引”。据 Microsoft Learn 索引架构指南，覆盖索引的优势在于”满足查询所需的数据全部存在于索引本身，只需读索引页、不必读表或聚集索引的数据页，从而减少整体磁盘 IO”。
判断一条索引是否覆盖某个查询，只需核对：查询在 WHERE、JOIN、GROUP BY 以及 SELECT 里用到的每一列，是否都落在这棵索引中（键列或非键列）。
三、键列 vs INCLUDE 非键列
据阿里云 PolarDB 文档的对照，普通非聚集索引中两类列职责不同：
| 属性 | 键列（Key） | INCLUDE 非键列 |
|---|---|---|
| 用于索引导航/查找 | 是 | 否 |
| 影响索引排序 | 是 | 否 |
| 参与唯一性约束 | 是 | 否 |
| 存于 B+ 树上层节点 | 部分（可能后缀截断） | 否，只存叶子节点 |
| 数据类型限制 | 必须可被索引 | 无（text/image 除外） |
INCLUDE 列不参与查找和排序，只贴在叶子节点，因此不会加宽索引键、不影响 WHERE/ORDER BY 效率，却能让查询直接读到这些列。Microsoft Learn 明确建议：把”只用于搜索和查找的列”作为键列，把”覆盖查询所需的其他列”作为非键列，这样索引既覆盖查询、键又足够窄。
四、创建语法与经典示例
-- 电商高频查询：按客户查最近订单的日期、金额、状态
SELECT OrderDate, TotalAmount, Status
FROM OrderHeader
WHERE CustomerID = 12345
ORDER BY OrderDate DESC;
据 CSDN 的 SQL Server 索引实战，最佳索引设计是：
CREATE NONCLUSTERED INDEX IX_OrderHeader_CustomerID_OrderDate
ON OrderHeader (CustomerID, OrderDate DESC)
INCLUDE (TotalAmount, Status);
CustomerID 是等值过滤列、放最左；OrderDate DESC 是排序列、放第二位；TotalAmount、Status 仅被 SELECT 用到，用 INCLUDE 放进叶子节点。三者齐备后，引擎从索引页直接读出所有返回列，Key Lookup 彻底消失。CSDN 文中测算：约 580 万行表加这 18 字节/行的 INCLUDE 数据，约增 100MB 存储，换来查询提速约 20 倍，代价划算。
MySQL 8.0+ 同样支持 INCLUDE（部分旧版本则把覆盖列直接列在复合索引尾部实现），PostgreSQL 用 INCLUDE 创建覆盖索引后执行计划显示 Index Only Scan。
五、覆盖索引的四大优势
据 Microsoft Learn、SQLServerCentral 与 cnblogs 的整理，核心收益如下：
消除回表随机 IO。这是首要优势——无需跳到数据页，磁盘 IO 从”索引 + 数据页”降到”仅索引页”，大批量命中行时性能差距尤为显著。
减少逻辑读与内存占用。索引通常比整行窄得多，只扫索引意味着更少的页被读入缓冲池，缓存命中率更高。
避免排序与临时表。若索引键列顺序已匹配 ORDER BY、且覆盖所有列，引擎可沿索引顺序直接输出，省去额外的 filesort（MySQL 的 Using filesort）。
提升并发与稳定性。回表少意味着锁与闩锁竞争下降，深翻页、大范围扫描类查询的响应更平稳，不易因随机 IO 打满磁盘。
六、不是越多列越好：覆盖索引的代价
据 Microsoft Learn 索引设计指南警示，覆盖索引是把查询结果”预先投影”进索引，代价是额外的存储、写入维护（INSERT/UPDATE/DELETE 都要同步更新这些非键列）和更宽的索引页。两条红线：
- 别把列堆太多：过宽的覆盖索引会膨胀存储与 IO，写放大可能抵消读收益。指南明确建议”避免创建含过多列的覆盖索引”。
- 高频更新列谨慎放 INCLUDE：被频繁改动的列放进索引叶子，每次更新都重写索引页；若表更新很频繁，回表难以避免，INCLUDE 收益下降。
实战原则是”窄而准”：只覆盖真正高频、且读多写少的查询列。
七、设计覆盖索引的执行步骤
据 SQLServerCentral 的”如何写一个好的覆盖索引”指南，顺序如下：
- 抓出高频查询，列出它用到的全部列，归类：过滤/连接/排序列、纯返回列。
- 把过滤（等值列优先）与排序列排进索引键，遵循最左前缀与”等值在前、范围在后”。
- 把纯返回列用
INCLUDE加入，使其驻留叶子节点。 - 跑
EXPLAIN：MySQL 看Extra是否出现Using index，PostgreSQL 看是否Index Only Scan，确认零回表。 - 评估列数与时序写频率，过宽或高频更新列及时回退，避免写放大。
八、与其他索引优化的衔接
覆盖索引常与”延迟关联””深分页优化”协同：深分页的延迟关联子查询若只取主键、且主键在索引里，本就是一次索引覆盖扫描（见 13141 篇）。它也是消除”索引失效后被迫回表”的关键手段——当查询列能被一棵索引完整覆盖时，即便过滤条件有限，也能拿到 Using index 的最优路径。
常见问题（FAQ）
覆盖索引是单独一种索引类型吗？
不是。它是非聚集索引的设计目标——让查询全部列都落在索引里，从而免回表，而非新索引种类。
INCLUDE 列和键列能互换吗？
不能乱换。只被 SELECT 的列放 INCLUDE 不影响查找排序；但只要参与过滤/排序/分组，就必须进键列，否则无法用于导航。
加了覆盖索引还慢怎么办？
看是否列过多导致写放大、或 INCLUDE 了高频更新列；用 EXPLAIN 确认是否真出现 Using index / Index Only Scan，没命中则需调整键列顺序或补齐过滤列。
