SQL 覆盖索引是如何减少 IO 的？

覆盖索引能避免回表，因其将查询所需所有字段存于B+树叶子节点，使数据库无需通过主键二次查找聚簇索引，从而消除额外随机IO。

覆盖索引为什么能避免回表

覆盖索引的核心作用是让查询所需的所有字段都包含在索引的 B+ 树叶子节点 中，这样数据库引擎查完索引就直接拿到结果，不用再根据主键去聚簇索引里二次查找（即“回表”）。回表本质是一次额外的随机 IO —— 尤其当数据量大、主键分散时，磁盘寻道开销显著。

常见错误现象：EXPLaiN 输出中 Extra 列出现 using index，说明命中覆盖索引；若出现 Using where; Using index 或 Using index condition，需结合 key_len 和 filtered 综合判断是否真覆盖；而一旦出现 Using where 且没 Using index，基本意味着要回表。

• 覆盖索引要求 select 字段、WHERE 条件字段、ORDER BY 字段、GROUP BY 字段全部被索引包含（或可推导）
• 联合索引顺序很重要：比如 INDEX(a, b, c) 能覆盖 WHERE a=1 AND b=2 ORDER BY c，但不能覆盖 WHERE b=2（无法跳过最左前缀）
• SELECT * 几乎不可能被覆盖，除非是唯一一张表且建了包含所有列的索引（不现实，也不推荐）

联合索引字段顺序如何影响 IO 节省效果

字段顺序决定 B+ 树的排序结构，也决定哪些查询能用上索引的“有序性”。顺序不对，即使字段全有，也可能触发文件排序（Using filesort）或全索引扫描，IO 并未真正减少。

使用场景举例：查询 SELECT user_id, status FROM orders WHERE shop_id = 123 AND status IN ('paid', 'shipped') ORDER BY created_at DESC。如果建索引为 INDEX(shop_id, status, created_at, user_id)，就能覆盖——因为 WHERE 条件用了前两个字段，ORDER BY 用了第三个，SELECT 的 user_id 在最后，全部落在同一棵索引树叶子节点里。

• 把等值查询字段（=）放最左，范围查询字段（IN、>）放中间，排序/分组字段紧随其后，最后才是 SELECT 中的其他字段
• 避免在索引中间插入高区分度但非查询条件的字段（如 uuid），会增大索引体积，间接增加 IO 次数（读更多页）
• created_at 是时间戳类型，升序存储；若查询用 ORDER BY created_at DESC，mysql 8.0+ 支持降序索引，否则仍可能触发 filesort

覆盖索引对 Buffer Pool 和磁盘页加载的影响

索引页通常比数据页小得多（尤其没 TEXT/BLOB 字段时），同样大小的内存页能缓存更多索引记录。这意味着更大概率在 Buffer Pool 中命中索引页，减少物理磁盘读；即使需要从磁盘加载，单次读取的页数也更少。

性能影响明显体现在高并发点查场景：比如订单详情页只显示编号、状态、金额，用 INDEX(order_no, status, amount) 后，QPS 上升时 Innodb_buffer_pool_reads 增长变缓，而 Innodb_buffer_pool_read_requests 持续上升——说明缓存效率提升。

• 索引列尽量用紧凑类型：比如用 TINYINT 存状态码，别用 VARCHAR(20) 存字符串
• 避免在覆盖索引里包含可空字段（NULL），会额外占用一个 bit 位，累积起来影响单页存储密度
• 如果表有 ROW_FORMAT=COMPRESSED，索引页压缩效果通常优于数据页，进一步放大 IO 优势

什么情况下覆盖索引反而增加 IO

不是所有“字段全在索引里”的情况都省 IO。索引太宽、维护成本高、或查询实际走不到它，反而加重负担。

典型反例：给大表加一个包含 10 个字段的联合索引，但业务中 90% 查询只用其中 2 个字段，且该索引因 WHERE 条件不匹配根本没被选中。这时索引不仅占空间，每次 INSERT/UPDATE 还要多写 10 个字段到多个索引页，引发更多随机写 IO。

• 用 SHOW INDEX FROM table_name 查看 Cardinality，如果远低于表行数，说明索引选择性差，优化器大概率弃用
• ALTER TABLE ... ADD INDEX 会锁表（5.6+ 支持 ALgoRITHM=INPLACE，但仍需拷贝索引数据，IO 峰值高）
• 覆盖索引无法加速 SELECT count(*)（除非是 MyISAM），因为 InnoDB 需遍历索引统计行数，和扫聚簇索引代价接近

真正节省 IO 的前提是：查询能稳定走这个索引，且索引本身足够窄、选择性足够好。否则只是把 IO 压力从查询时挪到了写入时。