非聚簇索引叶子节点只存索引列值和主键值，不存行数据；整行数据仅存于聚簇索引叶子节点，因此非主键查询需回表获取完整记录。
非聚簇索引的叶子节点只存主键值，不存行数据
InnoDB 的非聚簇索引（也叫二级索引）在 B+ 树叶子节点里，只保存两样东西：索引列的值 和对应的 主键值。它不存 name、age、email 等其他列的数据——哪怕你查的就是这些列。
比如表 users(id PK, name, email)，你在 name 上建了普通索引：
CREATE INDEX idx_name ON users(name);
执行 SELECT email FROM users WHERE name = 'Alice'; 时，MySQL 先在 idx_name 树里找到 name = 'Alice' 对应的 id = 123，但此时根本拿不到 email 值，必须拿着这个 123 去主键索引（聚簇索引）里再查一次整行。
聚簇索引才是唯一存完整行的地方
InnoDB 规定：整张表的行数据只能完整地存一次，就存在聚簇索引（也就是主键索引）的叶子节点里。所有非聚簇索引，本质上都是“指向主键的快捷方式”，不是数据副本。
- 主键查询（如
SELECT * FROM users WHERE id = 123）：直接走聚簇索引，一次定位，不回表 - 非主键条件 + 查询非索引列（如
WHERE name = 'Alice' AND SELECT email）：必回表 - 非主键条件 + 查询索引列本身（如
SELECT name FROM users WHERE name = 'Alice'）：不回表，是覆盖索引
为什么设计成这样？空间和维护成本决定的
如果每个非聚簇索引都把整行数据复制一份进去，那索引体积会爆炸式增长，尤其是大字段（TEXT、BLOB）、宽表、多索引场景下，写入性能和内存占用都会急剧恶化。
回表虽然引入了额外 I/O（尤其是磁盘随机读），但换来的是索引轻量、更新一致、存储可控。这是 InnoDB 在「查询延迟」和「写入/存储开销」之间做的明确取舍。
常见误判点：
-
EXPLAIN中type = ref或range不代表没回表，要看Extra列有没有Using index - 联合索引里漏掉查询字段，照样回表。例如
INDEX(a,b)支持SELECT a,b WHERE a=1，但SELECT a,b,c仍要回表 -
SELECT *几乎必然触发回表，除非你给所有列建了个包含全部字段的联合索引（不现实）
回表不是 bug，是 InnoDB 索引模型的自然结果
真正容易被忽略的是：回表是否发生，不取决于“有没有索引”，而取决于“查询的列是否全部落在当前使用的那个索引的定义列中”。哪怕你加了 10 个索引，只要 SELECT 的字段有任意一个不在所用索引里，就回表。
优化方向非常具体：看 EXPLAIN 的 key 和 Extra，补全覆盖索引，或改写查询减少返回字段。别指望引擎自动绕过这个底层约束。
