聚簇索引的叶子节点直接存储整行数据，是数据的物理组织方式；非聚簇索引叶子节点仅存索引列值和主键值，查询需回表，主键过大或频繁变更会显著影响性能。
聚簇索引的叶子节点直接存整行数据
聚簇索引不是“指向数据的索引”，它本身就是数据的组织方式。InnoDB 表中，PRIMARY KEY 对应的 B+Tree 的叶子节点里，存放的是完整的用户数据行（包括所有列），物理磁盘上的页（page）就是按该索引键顺序连续排列的。这意味着：
– 查询主键时，一次 B+Tree 查找就能拿到全部字段，无需额外 I/O；
– ORDER BY PRIMARY KEY 或 WHERE id BETWEEN 100 AND 200 这类范围扫描，能高效利用磁盘顺序读；
– 如果表没定义主键，InnoDB 会悄悄选一个 UNIQUE NOT NULL 列，或生成隐式 GEN_CLUST_INDEX，所以每张 InnoDB 表必然有且仅有一个聚簇索引。
非聚簇索引的叶子节点只存索引列 + 主键值
非聚簇索引（也叫二级索引、辅助索引）是独立于数据行之外构建的 B+Tree。它的叶子节点不存真实数据，只存两样东西：索引列的值 和对应行的 主键值。例如你对 email 建了索引：
CREATE INDEX idx_email ON users(email);那么该索引树的叶子节点类似：
('alice@example.com', 123)、('bob@example.com', 456)……这里的 123、456 是 users 表的主键。查 email = 'alice@example.com' 时，MySQL 先在 idx_email 树里找到 123，再拿着 123 回到聚簇索引树里查完整行——这个过程叫“回表”。
为什么非聚簇索引不存行指针而存主键
InnoDB 不用物理地址（如磁盘块号+偏移）作指针，是因为行可能被移动（比如页分裂、更新导致行迁移）。主键稳定且全局唯一，能可靠定位数据。这也带来两个实际影响：
– 非聚簇索引越宽（比如联合索引包含太多列），叶子节点体积越大，B+Tree 层数可能增加，查询变慢；
– 如果查询语句能被索引覆盖（SELECT email, created_at FROM users WHERE email = ?，且 created_at 也在 idx_email 中），就不用回表；否则每次都要二次查找聚簇索引；
– 主键选得过大（比如用 UUID 当主键），会让所有非聚簇索引的叶子节点都变胖，间接拖慢全表索引性能。
聚簇索引变更会重建整张表
因为聚簇索引决定了数据物理排序，一旦修改主键（如 ALTER TABLE ... DROP PRIMARY KEY 再加新主键），InnoDB 必须重排所有数据页——这是个锁表、耗 I/O 的操作。而非聚簇索引增删只是维护一棵独立 B+Tree，代价小得多。这也是为什么线上表轻易不动主键，以及为什么推荐用自增 BIGINT 而非随机字符串当主键：减少页分裂，让聚簇索引写入更紧凑。
