覆盖索引生效的前提是SELECT列表中每个字段都必须严格包含在同一索引中，漏掉、多出、含函数或表达式即失效；SELECT *天然互斥，EXPLAIN中出现Using index才表示命中。
覆盖索引对 SELECT 字段有硬性要求
覆盖索引生效的前提，是 SELECT 列表中的**每一个字段**都必须包含在同一个索引中。只要漏掉一个、多出一个、或用了表达式/函数，就立刻退化为回表查询。
常见错误现象：EXPLAIN 显示 type=ref 或 range，但 Extra 列没有 Using index —— 这说明索引被用来定位行，但没被用来取值。
- 联合索引
(a, b, c)，SELECT a, b✅ 覆盖；SELECT a, c❌ 不覆盖（跳过b，c无法直接从索引中获取） -
SELECT id, name FROM user WHERE status = 1，即使(status, id, name)是联合索引，也✅ 覆盖；但加个SELECT id, name, created_at就❌ 失效（created_at不在索引里） -
SELECT COUNT(*)在聚簇索引上可覆盖；但SELECT COUNT(id)若id是主键也✅，若id是普通索引且允许 NULL，则可能触发额外判断逻辑
关联查询中覆盖索引只作用于单表，不能跨表“共享”
很多人误以为给 orders 建了 (user_id, amount) 索引，再 JOIN users 时就能让两表都走覆盖索引 —— 实际上不可能。覆盖索引是单表语义，MySQL 每次只对一个表判断是否能覆盖。
典型失效场景：SELECT o.amount, u.name FROM orders o JOIN users u ON o.user_id = u.id WHERE o.status = 1
- 即使
orders有索引(status, user_id, amount)，o.amount可覆盖 ✅ - 但
u.name必须从users表数据页读取，除非users单独建了覆盖索引如(id, name)，且查询条件命中该索引的最左前缀 - 如果
users只有主键索引，而name不在其中，那就必然回表
SELECT * 与覆盖索引天然互斥
SELECT * 几乎总是导致覆盖索引失效，因为聚簇索引以外的二级索引都不包含所有列（尤其是大字段如 TEXT、BLOB），优化器会直接放弃覆盖判断。
更隐蔽的问题：即使表只有几列，且你确认它们都在某个联合索引里，SELECT * 仍可能失效 —— 因为 MySQL 会检查该索引是否包含 NULL 列、是否含前缀索引、是否被标记为 NOT NULL 等细节，任一不满足就拒绝覆盖。
- 安全做法：显式列出需要的字段，且确保它们全部落在同一联合索引中
- 验证方式：
EXPLAIN FORMAT=TREE（8.0+）或看Extra是否出现Using index，不是Using index condition - 注意：
Using index condition表示用了 ICP（索引下推），和覆盖索引无关
隐式字段和计算字段会悄悄破坏覆盖性
看起来没写函数，但某些语法会引入隐式转换或计算，让字段脱离索引上下文。
例如：SELECT id + 1, name FROM user WHERE id = 100，即使 (id, name) 是联合索引，id + 1 是计算字段，无法从索引中直接得值，覆盖失效。
-
SELECT COALESCE(name, 'N/A')❌ 覆盖失效（函数包裹） -
SELECT name AS alias_name✅ 无影响（别名不改变字段来源） -
SELECT UNIX_TIMESTAMP(create_time)❌ 即使create_time在索引里，函数调用导致无法覆盖 - 时间字段用
DATE(create_time)查询时，哪怕索引是(create_time)，也既不走范围扫描，也不覆盖
最容易被忽略的一点：覆盖索引不是“用了索引就自动覆盖”，而是“查询字段集 ⊆ 索引字段集”这个数学关系必须严格成立；任何看似微小的类型转换、别名歧义、或隐式 NULL 处理，都会让这个等式崩塌。
