聚簇索引叶子节点必须存储整行数据，这是其本质要求；非聚簇索引（二级索引）叶子节点仅存索引列和主键值，查询需回表，且一张表只能有一个聚簇索引、可建多个非聚簇索引。
聚簇索引决定了叶子节点必须存整行数据
InnoDB 的主键索引就是聚簇索引，而聚簇索引的定义就是：索引的叶子节点直接存储完整的行记录。这不是设计选择，而是聚簇索引的本质要求——数据行的物理存储顺序与主键索引顺序完全一致。SELECT * FROM t WHERE id = 123 这类查询命中主键后，无需额外跳转，直接从叶子页读出全部字段。
非叶子节点只存 key + 指针，是为了压高扇出、降低树高
如果非叶子节点也存数据（像 B 树那样），单个节点能容纳的 key 数量会大幅下降。假设页大小为 16KB，BIGINT 主键占 8 字节，指针占 6 字节，那一个非叶子节点可存约 1170 个 key；一旦混入数据，这个数字可能跌到几十。树高从 3 层涨到 4 或 5 层，意味着每次查询多 1–2 次磁盘 IO ——这对千万级表是致命的。
二级索引叶子节点不存完整行，但必须存主键值
这是关键区别：WHERE name = 'Alice' 走的是二级索引，它的叶子节点只存 name 和对应的 id（主键值），不存其他列。查到 id 后，还得回表——即拿着这个 id 再去聚簇索引里查一次。所以二级索引本身不“包含完整行数据”，只有聚簇索引才这样。
- 如果你建了联合索引
(a, b)，它仍是二级索引，叶子存的是a、b和主键id，不是整行 -
SELECT a, b FROM t WHERE a = ?可以用该索引覆盖查询，因为所需字段全在叶子节点上，不用回表 - 但
SELECT a, b, c FROM t WHERE a = ?就必须回表，除非c也在索引里
为什么不能让二级索引也存整行？空间和维护成本爆炸
一张表如果有 5 个二级索引，每个都存完整行数据，那磁盘占用就是 6 倍（1 份聚簇 + 5 份冗余）。更严重的是更新代价：任意一行修改，所有二级索引叶子节点都要同步更新，写放大严重。InnoDB 用主键值做间接引用，既保证一致性，又把冗余控制在最小粒度。
真正容易被忽略的点是：所谓“叶子节点包含完整行数据”，仅对聚簇索引成立；而聚簇索引的存在本身不可选——哪怕没定义主键，InnoDB 也会悄悄生成隐藏的 row_id 作为聚簇索引。这意味着，任何 InnoDB 表的物理存储，永远绕不开这个 B+ 树结构约束。
