聚簇索引即数据按主键顺序直接存储在b+树叶子节点中；innodb以primary key为聚簇索引，无主键时选not null unique列或隐式row_id；二级索引叶子存主键值以避免行迁移导致的指针更新。
聚簇索引的物理存储到底长什么样
聚簇索引不是“加了索引就聚簇”，而是数据行直接按索引键顺序存放在B+树叶子节点里。InnoDB中，PRIMARY KEY自动成为聚簇索引——这意味着整张表的数据文件（.ibd）本身就是一颗B+树，叶子节点存的是完整的行记录。
如果建表时没定义主键，InnoDB会按以下顺序选聚簇索引：先找NOT NULL UNIQUE列；找不到就隐式生成一个6字节的row_id列作为聚簇索引。这个row_id不可见、不可查，但会影响插入性能和页分裂行为。
- 聚簇索引查询主键时是“一次IO”：直接定位到叶子页，拿到完整行
- 范围扫描（如
WHERE id BETWEEN 100 AND 200）天然有序，效率高 - 更新主键值会导致整行移动（可能跨页），代价远高于更新非主键字段
为什么二级索引叶子节点存的是主键值而不是行指针
InnoDB的二级索引（即非聚簇索引）叶子节点不存磁盘地址或行偏移，而是存对应记录的PRIMARY KEY值。这是为了规避行迁移问题：一旦行物理位置变动（比如页分裂、UPDATE导致行变长），所有二级索引都不需要更新指针——只需用主键值回表查即可。
这也带来一个关键约束：二级索引的WHERE条件若不能覆盖所需字段，就必须回表。例如SELECT name FROM user WHERE email = 'a@b.c'，即使email上有索引，只要name不在该索引中，就得拿着查到的主键再去聚簇索引里捞一次。
立即学习“Java免费学习笔记（深入）”；
- 联合索引
(a, b)能覆盖SELECT a, b FROM t WHERE a = ?，无需回表 - 但如果写成
SELECT * FROM t WHERE a = ?，哪怕a是联合索引首列，仍要回表取其他列 -
EXPLAIN中Extra字段出现Using index condition说明用了ICP（索引下推），但不等于免回表
MyISAM的非聚簇索引和InnoDB有本质区别
MyISAM的索引文件（.MYI）和数据文件（.MYD）完全分离，所有索引（包括主键）都是非聚簇的：索引叶子节点存的是行在.MYD文件中的offset（偏移量）。这意味着：
- MyISAM没有真正的“聚簇索引”，它的主键索引只是逻辑上唯一+非空，物理上仍是二级索引结构
- 主键查询需两次IO：先查索引得offset，再按offset读数据文件
- 没有“回表”概念，但有“二次寻址”；也没有“因主键更新导致行移动”的问题
这也是为什么MyISAM支持INSERT DELAYED、并发插入更简单——它不维护行物理顺序。
面试常问的“主键选UUID还是自增？”背后是聚簇索引特性
用UUID做主键，写入时新值随机分布，极易引发页分裂和大量随机IO；而BIGINT AUTO_INCREMENT保证递增写入，基本顺序追加，页利用率高、缓存友好。
但注意：这不是UUID本身的问题，而是它破坏了聚簇索引“有序写入”这一核心优势。如果你强制用UUID，又想缓解影响，可考虑：
- 使用
UUID_TO_BIN(UUID(), 1)将UUID转为二进制并倒序存储（MySQL 8.0+） - 业务层生成时间前缀+随机后缀的“有序UUID”，再转为
BINARY(16) - 接受写入性能损失，但确保
innodb_page_size足够大（如16K）、innodb_fill_factor调低（如80）预留页空间
SELECT UUID_TO_BIN('6b14e5a0-9f8c-11ef-9f0a-00155d012345', 1);真正容易被忽略的是：即使你没显式定义主键，只要表里有NOT NULL UNIQUE列，InnoDB就可能拿它当聚簇索引——而这类列往往不是递增的。上线前务必用SHOW CREATE TABLE确认实际聚簇索引列。
