覆盖索引是否生效只看EXPLAIN的Extra列是否为Using index；出现Using index表示SELECT、WHERE、ORDER BY、GROUP BY所有字段均被同一二级索引完全覆盖，无需回表；其他如Using index condition或空值则未覆盖。
覆盖索引不是“建了索引就自动生效”，它是否起作用，只看 EXPLAIN 的 Extra 列是否出现 Using index —— 其他任何推测都不算数。
怎么看自己真没回表？盯死 EXPLAIN 的 Extra 列
MySQL 优化器是否走覆盖路径，唯一可信信号就是执行计划里 Extra 字段的值：
-
Using index→ ✅ 真覆盖，所有字段（SELECT、WHERE、ORDER BY、GROUP BY）都在同一二级索引中，不回表 -
Using where; Using index→ ✅ 也覆盖，同时用了索引下推（ICP）和覆盖 -
Using index condition→ ❌ 只用了 ICP，SELECT字段仍要回表取 - 空值、
Using where、Using filesort、Using temporary→ ❌ 没覆盖，大概率正在回表
特别注意：SELECT * 几乎永远触发不了 Using index，因为二级索引叶子节点不含所有字段；哪怕你建了 (a,b,c) 索引，SELECT * 也会让优化器放弃覆盖路径。
为什么建了联合索引还是回表？顺序和字段缺一不可
覆盖能力严格依赖索引定义顺序和查询结构。例如索引 idx_status_city_name_email(status, city, name, email)：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 能覆盖：
SELECT name, email FROM t WHERE status = 1 AND city = 'shanghai'（条件列最左连续，SELECT列全在索引后缀） - 不能覆盖：
SELECT email FROM t WHERE city = 'shanghai'（city不是最左列，索引根本用不上） - 能覆盖但低效：
SELECT status, name FROM t WHERE status = 1（跳过中间city，仍可覆盖，但空间浪费）
主键（如 id）自动包含在二级索引叶子节点里，所以 SELECT id, name 比 SELECT name 更容易被覆盖，无需显式把 id 加进索引定义。
哪些写法会让覆盖索引“悄悄失效”？
这些常见操作会直接导致优化器弃用覆盖路径，Extra 不再显示 Using index：
- 对索引字段用函数：
WHERE YEAR(created_at) = 2025→ 改成WHERE created_at >= '2025-01-01' AND created_at - 隐式类型转换：
WHERE mobile = 13812345678（mobile是VARCHAR）→ 改成WHERE mobile = '13812345678' - 左模糊查询：
WHERE name LIKE '%ton'→ 索引无法定位起点，优化器可能直接全表扫描 -
SELECT中含TEXT/BLOB字段 → 这类字段不能完整存入索引页，前缀索引也不参与覆盖判断 -
ORDER BY或GROUP BY字段不在索引里 → 即使其他字段都覆盖，也可能触发Using filesort或回表
覆盖索引不是越宽越好：宽度、更新频率和查询模式必须权衡
加字段进索引反而拖慢查询，不是玄学：
-
VARCHAR(255)实际按最大长度预留空间（utf8mb4下最多占 1020 字节），极易撑爆单页，B+ 树层级加深 -
BIGINT主键会让所有二级索引变大一倍（因叶子存主键值），间接放大覆盖索引体积 - 高频更新字段放进覆盖索引，每次
UPDATE都要同步刷多个索引页，写性能明显下降 - 当查询返回大量行（比如 > 20% 表数据），优化器可能主动放弃覆盖索引——顺序读聚簇索引页比随机回表更快
真正关键的是：优先覆盖高频、低更新、小体积字段；对长文本或高更新字段，宁可回表，也不硬塞进索引。
