前缀索引不能用于覆盖索引，因为其b+树叶子节点仅存储字段前n个字节，不包含完整值，导致查询所需字段无法全部从索引中获取，必须回表取原始数据，违背覆盖索引“无需回表”的核心要求。
前缀索引为什么不能用于覆盖索引
MySQL 的覆盖索引（Covering Index）要求：查询所需的所有列，都必须完整地、原样地存在于索引的 B+Tree 叶子节点中。这样执行器就无需回表查主键聚簇索引，直接从二级索引里拿到全部数据。
但前缀索引只存储字段的前 N 个字节（比如 email(6)），而你 SELECT 的可能是完整 email 值。这时索引叶子节点里压根没有完整值，MySQL 只能先用前缀索引快速定位记录位置，再回到聚簇索引里把整行捞出来——也就是「回表」。这一步就打破了覆盖索引的前提。
常见错误现象：EXPLAIN 显示 type=ref 或 range，但 Extra 字段里没有 Using index，反而出现 Using where; Using index condition 或干脆是空——说明没走覆盖。
前缀索引和完整索引在 B+Tree 结构上的根本差异
关键不在“能不能查”，而在“叶子节点存了什么”。
- 完整索引（如
ADD INDEX idx_email (email)）：B+Tree 叶子节点存的是完整的email值 + 主键（或主键ID），所以只要SELECT email就能覆盖。 - 前缀索引（如
ADD INDEX idx_email_6 (email(6))）：叶子节点只存截断后的 6 字节 + 主键，email原始值被丢弃了，无法还原。
这就导致：即使你只查 SELECT email，MySQL 也必须回表取完整值；如果还查了 name、id 等其他列，那更不可能覆盖。
哪些查询会意外触发回表（即使看起来很“简单”）
-
SELECT email FROM users WHERE email LIKE 'abc%'
→ 前缀索引能加速定位，但 SELECT 的是完整email，仍需回表 -
SELECT email, created_at FROM users WHERE email(6) = 'zhangs'
→ 条件用了前缀，但 SELECT 的email不是前缀，照样回表 -
SELECT COUNT(*) FROM users WHERE email LIKE 'test%'
→ 即使不显式 SELECT email，只要 WHERE 依赖前缀索引，且没有其他索引能覆盖 COUNT，就无法避免访问数据行
注意：COUNT(*) 在 InnoDB 中本质是遍历聚簇索引，除非有能覆盖的二级索引（比如 INDEX(email) 且只 COUNT(email) 非 NULL），否则前缀索引对 COUNT 几乎无加速作用。
真正想用覆盖索引，该怎么做
- 如果业务只需要前缀（比如校验邮箱前6位是否重复），那就
SELECT LEFT(email, 6)并确保 WHERE 和 SELECT 都只涉及这个前缀长度，同时把该表达式单独建函数索引（MySQL 8.0+ 支持）； - 更实际的做法：放弃前缀索引，改用更短的业务字段（如提取域名或哈希值）建完整索引；
- 或者接受空间代价，建完整索引 + 覆盖所需列（如
INDEX(email, name, status)），前提是这些列本身不长。
容易被忽略的一点：前缀索引的“节省空间”优势，在 SSD 成本大幅下降的今天，往往不如一次回表带来的性能损耗来得实在——尤其当 QPS 高、延迟敏感时。
