覆盖索引能减少磁盘读取，因为它使查询所需的所有列（WHERE、SELECT等）均被同一索引包含，避免回表产生的二次I/O；SQL Server用INCLUDE优化非键列，MySQL 8.0+则依赖二级索引隐式包含主键。
覆盖索引为什么能减少磁盘读取
因为 SQL Server（或 MySQL、PostgreSQL）执行查询时，如果 SELECT 列和 WHERE 条件列都能被同一个索引“覆盖”，优化器就不用回表——也就是跳过对聚簇索引/主键索引的二次随机 I/O。这直接减少了磁盘寻道次数，尤其在机械硬盘或高并发 OLTP 场景下效果明显。
常见错误现象：SET STATISTICS IO ON 显示逻辑读很高，但 sys.dm_exec_query_stats 里 physical_reads 也频繁上升；执行计划里出现“Key Lookup”或“Clustered Index Seek + RID Lookup”节点。
- 覆盖索引必须包含所有
WHERE、JOIN、ORDER BY和SELECT中用到的列（不含计算列或大对象类型如TEXT/XML） -
INCLUDE子句只存非键列，不参与排序，适合放SELECT中的展示字段（比如SELECT name, email WHERE user_id = ?，可建INDEX IX_user_id ON users(user_id) INCLUDE (name, email)） - SQL Server 中，
INCLUDE列不计入索引层级高度，但会增大叶级页体积；MySQL 8.0+ 的二级索引天然覆盖主键，但非主键列仍需显式包含
存储过程中怎么验证是否走覆盖索引
不能只看 EXEC sp_executesql 的执行计划截图——存储过程可能因参数嗅探复用低效计划。得在过程内加提示，或用实际参数重编译观察。
使用场景：过程里有类似 SELECT order_id, status, amount FROM orders WHERE customer_id = @cid AND created_at > @dt，但没建合适索引，每次调用都扫几千行。
- 在存储过程开头加
SET STATISTICS XML ON，执行后看实际计划中是否有Index Seek节点且无Key Lookup - 检查
sys.dm_exec_cached_plans+sys.dm_exec_sql_text，确认缓存计划是否用了预期索引（看physical_operator和index_name属性） - 避免用
SELECT *——它会让任何索引失效，哪怕你建了全字段索引，优化器也可能因统计信息陈旧弃用
哪些列不该放进覆盖索引
不是所有 SELECT 出来的列都值得塞进 INCLUDE。放错会拖慢写入、撑大内存、甚至让优化器放弃使用该索引。
性能影响：每多一个 INCLUDE 列，索引叶级页就变大，缓冲池命中率下降；INSERT/UPDATE 涉及这些列时，要同步更新多个索引副本。
- 别放
MAX类型：如varchar(max)、varbinary(max)、xml—— SQL Server 不允许，MySQL 会自动转成 LOB 引用，失去覆盖意义 - 别放高频更新列：比如
last_login_time或status_version，每次更新都要改索引页，放大写放大锁 - 别为单次调用建专用索引：如果某个存储过程只在报表时段跑一次，而索引长期闲置，反而增加维护负担
SQL Server 和 MySQL 在覆盖索引上的关键差异
同一套设计思路，在两个系统落地时行为不同，容易踩坑。
兼容性影响：迁库、共用 ORM、或 DBA 按 SQL Server 经验给 MySQL 建索引，常导致无效覆盖。
- SQL Server 支持
INCLUDE，且允许在唯一索引/主键上加INCLUDE列；MySQL 5.7 不支持INCLUDE，必须把所有列都放进索引键（顺序敏感！），MySQL 8.0+ 仍不支持语法，靠隐式包含主键实现部分覆盖 - MySQL 的联合索引最左前缀生效，
WHERE a = ? AND b > ?可用(a,b,c)索引覆盖c，但WHERE b = ?就完全用不上——SQL Server 的索引跳过首列仍可能 Seek（取决于统计信息和版本） - 两者对
NULL值处理一致：索引默认存NULL，但WHERE col IS NULL是否走索引，取决于是否在索引定义中显式允许NULL（SQL Server 默认允许，MySQL 取决于列定义）
最易被忽略的是统计信息更新时机：SQL Server 默认自动更新，但大表上可能滞后；MySQL 的 innodb_stats_auto_recalc 默认开，但小表变更少时，优化器仍可能选错索引。不查 DBCC SHOW_STATISTICS 或 SHOW INDEX 的 Cardinality，光看执行计划容易误判。
