InnoDB表必有且仅有一个聚簇索引，主键索引即聚簇索引；无主键时选首个UNIQUE NOT NULL索引，否则隐式生成ROW_ID聚簇索引；二级索引叶子节点只存索引列值和主键值，查询需回表。
MySQL里没有“非聚集索引”这个标准术语——InnoDB 引擎只有一种聚集索引（Clustered Index），其余全是二级索引（Secondary Index）。所谓“非聚集索引”是其他数据库（如 SQL Server）的说法，直接套用到 MySQL 容易引发误解。
为什么 InnoDB 表一定有且只有一个聚集索引
这是 InnoDB 存储引擎的强制设计：数据行必须按某种顺序物理存放，而这个顺序只能由一个 B+ 树决定。它不接受“无序表”的存在。
- 显式定义了
PRIMARY KEY→ 该主键列自动成为聚集索引 - 没主键但有
UNIQUE NOT NULL索引 → 第一个满足条件的索引被选为聚集索引 - 既无主键也无
UNIQUE NOT NULL→ InnoDB 隐式创建隐藏列ROW_ID（6 字节自增），并以此构建聚集索引，名称为GEN_CLUST_INDEX
这意味着：哪怕你 DROP PRIMARY KEY，只要没补上新的 UNIQUE NOT NULL，InnoDB 就会悄悄用 ROW_ID 继续维持聚集结构——你根本看不到它，但它真实影响写入性能和查询路径。
二级索引的叶子节点到底存什么
二级索引（比如 CREATE INDEX idx_name ON t(name)）的 B+ 树叶子节点，**不存数据行本身，也不存磁盘地址，只存两样东西：name 的值 + 对应行的聚集索引键（通常是主键值）**。
例如：
SELECT * FROM t WHERE name = 'Alice';
执行过程是：
- 先查
idx_name树，找到所有name = 'Alice'的叶子项，每项带一个主键 ID（比如id = 105） - 再拿着这些 ID 去聚集索引树里逐个回查，拿到完整行数据
这个“先查二级索引、再查聚集索引”的动作叫「回表」。如果查询只需要 name 和 id，而你建的是 INDEX idx_name_id ON t(name, id)，那就能避免回表——这就是覆盖索引。
什么时候会误以为“建了索引却没走”
常见错觉来源不是索引没建好，而是没意识到聚集索引的存在逻辑：
-
ORDER BY非主键字段 +LIMIT：若没有对应二级索引，MySQL 可能放弃索引，改用文件排序（Using filesort），因为聚集索引无法按该字段物理排序 - 联合索引中，
WHERE a = ? AND b > ? ORDER BY c：即使(a,b,c)有索引，c在b是范围查询时无法用于排序——B+ 树只保证最左前缀有序，b > ?之后的c是乱序的 - 主键用
VARCHAR或UUID：会导致数据插入随机写入，频繁页分裂，聚集索引的物理连续性被破坏，不仅慢，还会让二级索引的指针跳转更分散
真正关键的不是“有没有索引”，而是“聚集索引的排序是否匹配你的高频查询模式”。很多慢查问题，根源不在缺失二级索引，而在聚集索引键选得不合理。
