因为物理行指针在InnoDB中不可靠，页分裂和行移动会导致地址频繁变化，存主键值可避免批量更新二级索引，仅需维护聚簇索引；代价是二级索引体积增大、树高增加、回表开销上升。
二级索引叶子节点为什么存主键值而非行指针
因为物理行指针在 InnoDB 中不可靠 —— 页分裂、行移动会导致物理地址频繁变化，如果二级索引直接存指针，每次数据重排都得批量更新所有二级索引，开销爆炸。
存主键值是更轻量的解耦设计：主键值本身不变（除非显式 UPDATE 主键），数据页怎么挪、怎么分裂，二级索引叶子节点完全不用动。维护成本从“全索引重写”降为“只改聚簇索引”。
这背后隐含一个关键事实：InnoDB 的聚簇索引本身就是按主键组织的 B+Tree，主键天然稳定、全局唯一，是最合适的逻辑锚点。
存主键值带来的实际代价有哪些
最直接的影响是二级索引体积变大，尤其是当主键本身很长时：
-
BIGINT主键（8 字节）：一页 16KB 可存约 1000+ 条二级索引记录 -
VARCHAR(64)主键（平均 40 字节）：同一页可能只剩 200–300 条 - 主键长度翻 5 倍 → 二级索引页数可能翻倍 → 树高增加 → 查询多一次磁盘 I/O
另一个常被忽略的副作用是：SELECT * 配合二级索引会强制回表，而回表路径长度直接受主键大小影响 —— 主键越长，从二级索引查到主键值后，再去聚簇索引定位那条记录的开销也越大。
MyISAM 为什么能用行指针而 InnoDB 不行
MyISAM 的数据文件（.MYD）是纯堆表结构，行物理位置固定，除非 OPTIMIZE TABLE，否则不会自动重排；它的索引文件（.MYI）直接存 row_number 或文件偏移量，足够稳定。
InnoDB 没有这种奢侈条件：INSERT / UPDATE / DELETE 都可能触发页分裂、合并、数据迁移，物理地址随时失效。它必须依赖逻辑标识（主键）来维持索引一致性。
换句话说：不是 InnoDB “不想”用指针，而是它的存储引擎机制决定了指针无法长期有效。
什么时候主键长度的影响会被放大
以下场景会让主键长度对二级索引的负面影响特别明显：
- 表上有大量二级索引（比如 5+ 个），每个都在重复存储同一份主键值
- 高频执行
WHERE+ 二级索引 +ORDER BY（需要排序二级索引页，页越多越慢） - 使用
UNIQUE约束但没设主键，InnoDB 自动选一个非空唯一列作聚簇索引 —— 若该列是VARCHAR(200)，后果很严重 - 联合索引中包含长主键字段（如
(status, id)，而id是VARCHAR(64)）—— 实际上等于把长主键又复制了一遍
真正容易被忽略的点是：主键长度的影响不只体现在写入时的页分裂，它会在所有二级索引的生命周期里持续拖慢查询、增大内存占用、提高 buffer pool 压力 —— 这种代价是静默累积的。
