覆盖索引能避免回表，但需SELECT、WHERE、ORDER BY、GROUP BY所有字段均包含在同一二级索引中；否则仍会回表，导致大量随机IO。
覆盖索引能直接避免回表，但必须让 SELECT、WHERE、ORDER BY、GROUP BY 中用到的所有字段都落在同一个二级索引里——否则哪怕只差一个字段，InnoDB 仍会触发回表。
为什么 EXPLAIN 显示 type=ref 却还是慢？
这是典型回表现象：二级索引查到了主键，但查询要返回非索引字段（比如 SELECT name, email FROM user WHERE age = 30），MySQL 不得不拿着每个匹配的 id 回聚簇索引逐行捞数据。
- 每回一次表 = 一次随机 IO（尤其机械盘，延迟可达 10ms 级）
- 如果
WHERE age = 30匹配 5000 行，就要做 5000 次随机 IO -
EXPLAIN的Extra列若没出现Using index，就说明没走覆盖索引
CREATE INDEX 时字段顺序怎么排？
顺序错，覆盖索引就白建。核心原则是：先过滤，再输出，最后排序/分组。
-
WHERE条件字段必须放最左（满足最左前缀） - 多个
WHERE字段按区分度从高到低排（例如status区分度常低于created_at，但高基数字段优先） -
SELECT字段跟在后面，无需主键——InnoDB 二级索引叶子节点天然存主键，它自动“免费附赠” -
ORDER BY字段若与WHERE字段不重叠，也得塞进索引末尾，否则会触发Using filesort
示例：优化 SELECT id, name, city FROM shop WHERE status = 'open' AND score > 4.5 ORDER BY updated_at DESC，应建 CREATE INDEX idx_shop_status_score_updated ON shop(status, score, updated_at, name)（id 不需显式写，它是聚簇索引键，自动包含）。
哪些操作会让覆盖索引“失效”？
不是建了联合索引就万事大吉，这些常见写法会让 MySQL 放弃覆盖路径：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 在
SELECT *中使用——哪怕索引包含全部字段，*也会让优化器不敢保证列顺序和 NULL 属性，倾向回表 -
WHERE中对索引字段用函数：WHERE YEAR(created_at) = 2025→ 改成WHERE created_at >= '2025-01-01' AND created_at - 模糊查询左模糊：
WHERE name LIKE '%ton'→ 无法用索引定位起点，只能全扫索引树，即使字段全在索引里，也因扫描量过大被优化器判为不如全表扫描 -
OR连接条件中任一侧无索引：如WHERE age = 25 OR city = 'Shanghai'，若city无索引，整个条件放弃索引
验证是否真覆盖：执行 EXPLAIN 后紧盯 Extra 列，只有出现 Using index 才算成功；若出现 Using where; Using index 也 OK，但 Using index condition 表示用了 ICP（索引下推），不等于覆盖。
覆盖索引不是万能解药
它省 IO，但代价是磁盘空间和写放大。特别要注意：
- 索引越宽（字段越多、字符越长），B+ 树层级越深，范围扫描成本越高
- 频繁更新的字段放进覆盖索引，每次
UPDATE都要同步刷多个索引页 - 对
TEXT/BLOB字段建覆盖索引无效——它们不存于索引页，只存指针，必然触发回表 - 当
WHERE条件匹配行数超过总行数约 20%，优化器大概率放弃索引走全表——此时覆盖索引毫无意义
真正关键的不是“有没有索引”，而是“这个查询在真实数据分布下，是否值得走索引”。别迷信 EXPLAIN 的 key 列显示了索引名，得看 rows 和 Extra 一起判断。
