innodb二级索引叶子节点只存索引列值和主键值，不存整行数据，以避免冗余、更新异常及写放大；覆盖索引生效需查询所有字段均包含在同一联合索引中且explain显示using index。
因为存整行会导致严重的数据冗余和更新异常，InnoDB 用主键值作为“稳定跳转凭证”来规避行迁移问题。
二级索引叶子节点存主键值，不是设计偷懒，而是存储约束
InnoDB 的聚簇索引（主键索引）已经负责物理存放整行数据；所有二级索引必须与之解耦，否则每新增一个二级索引，就得复制一份完整行——10 个索引 = 10 倍磁盘占用。更致命的是，一旦某行被 UPDATE 导致变长、页分裂或移动位置，所有二级索引的“行地址指针”都得同步更新，写放大不可控。
用主键值代替物理地址，就绕开了这个问题：主键不变，行在哪不重要，回表时靠聚簇索引自己定位即可。
-
INSERT/UPDATE/DELETE只需维护聚簇索引 + 涉及的二级索引键值，无需批量修正“指针” - 主键是逻辑标识，天然稳定；而磁盘页偏移、文件块号等物理地址在页分裂后必然失效
- 即使主键是
BIGINT（8 字节），也比一行几十上百字节小得多，空间开销可控
为什么不能让二级索引也存整行？B+Tree 结构不允许
B+Tree 的设计原则是非叶子节点只存键和指针，数据全在叶子节点。但 InnoDB 对两类索引做了硬性分工：
- 聚簇索引叶子节点 = 整行数据（
ROW_FORMAT=COMPACT下含隐藏列、事务ID等） - 二级索引叶子节点 = 索引列值 + 主键值（仅这两部分，不存任何其他列）
这个限制不是 MySQL “没实现”，而是 InnoDB 存储引擎从架构上就禁止二级索引叶子节点携带非索引字段。你建 INDEX(email)，哪怕 email 列本身只有 50 字节，叶子节点里也只放这 50 字节 + 主键值（比如 id BIGINT 占 8 字节），name、created_at 等字段绝不会出现。
覆盖索引能避免回表，但前提是“字段全在索引定义里”
所谓“避免回表”，本质是 MySQL 发现你要的所有字段（SELECT、WHERE、ORDER BY、GROUP BY 涉及的列）都在同一个二级索引的 B+ 树叶子节点中，于是直接返回，不再去聚簇索引捞数据。
-
SELECT id, email FROM users WHERE email = 'a@b.com'→ 有INDEX(email)就能覆盖（id是主键，天然存在） -
SELECT email, status FROM users WHERE email = 'a@b.com'→ 必须建INDEX(email, status)，否则status不在叶子节点，必回表 -
EXPLAIN中看到Extra: Using index才算真正覆盖；若出现Using where; Using index或纯Using where，说明仍发生回表
很多人误以为“加了索引就能覆盖”，其实关键在联合索引列的顺序和完整性——缺一列，就多一次随机 I/O。
主键越小，二级索引整体越紧凑，这点容易被忽略
每个二级索引的叶子节点都带一份主键值，所以主键类型直接影响所有二级索引体积：
- 主键用
INT（4 字节）→ 每条索引记录省 4 字节，万级数据就省下几十 KB - 主键用
BIGINT（8 字节）→ 所有二级索引体积翻倍，B+ 树单页存的键值对减少，树高可能增加一层 - 主键无序（如 UUID）→ 插入引发频繁页分裂，二级索引碎片率上升，范围扫描性能下降
这不是理论推演，是 InnoDB 页结构（16KB 默认）和 B+Tree 层级计算可验证的事实。线上表如果主键选型不当，二级索引膨胀会悄无声息拖垮查询吞吐。
