非聚簇索引叶子节点只存索引列值和主键值，不存完整数据行；查询时若SELECT字段超出索引列范围，需用主键回表查聚簇索引，即“回表查询”。
非聚簇索引的叶子节点只存主键值，不是数据本身
InnoDB 的非聚簇索引（也叫二级索引）B+ 树叶子节点里，只存索引列值 + 对应行的主键值，不存任何其他字段。比如你建了 INDEX idx_name ON user(name)，查 WHERE name = 'Alice' 时，MySQL 能快速定位到匹配的叶子节点，但那里面只有 name 和 id（假设 id 是主键），没有 email、age 等字段。
所以只要 SELECT 的字段超出了这个索引定义的列范围，就必须拿着查到的 id 去聚簇索引（也就是主键索引）里再查一次——这就是回表的物理来源。
EXPLAIN 中 Extra = Using index 才真不回表
很多人误以为“用了索引”就不回表，其实关键看 EXPLAIN 输出的 Extra 列：
-
Using index：说明查询所需所有字段都在当前索引的定义列中，走的是覆盖索引，不回表 -
Using where; Using index：也是覆盖索引，只是多了 WHERE 过滤逻辑 - 空着、或出现
Using filesort/Using temporary：大概率回表了（除非只查索引列）
例如 INDEX(a,b) 支持 SELECT a,b FROM t WHERE a=1（不回表），但 SELECT a,b,c 或 SELECT * 必然触发回表——哪怕 c 上也有单独索引，MySQL 也不会拼多个二级索引去凑字段。
为什么设计成这样？不是为了省空间，而是为了写一致性
回表不是设计缺陷，是 InnoDB 主动做的权衡：
- 如果每个二级索引叶子节点都存整行数据，更新任意字段都要同步改所有索引，写放大严重
- 只存主键值，更新非索引列时，只需改聚簇索引一页；更新索引列时，也只需改对应二级索引页 + 聚簇索引页，可控
- 主键值通常很短（如
BIGINT），索引体积小、B+ 树层级低、缓存友好
换句话说：用一次额外的 B+ 树查找（回表），换来了索引体积压缩、更新性能稳定、崩溃恢复简单。这不是妥协，是明确取舍。
没主键时回表照常发生，只是主键变隐式 row_id
即使建表时没定义 PRIMARY KEY，InnoDB 也会自动生成隐藏的 db_row_id 作为聚簇索引主键。此时所有二级索引的叶子节点存的仍是这个隐式主键值，回表行为完全不变——只是你 EXPLAIN 看不到它，SELECT * 仍要回表拿全量行数据。
真正容易被忽略的是：回表与否，和有没有索引无关，只取决于 SELECT 字段是否全部落在当前使用的那个索引的 COLUMNS 定义里。哪怕你加了 20 个索引，只要有一个字段不在所用索引中，就回表。
