聚簇索引即主键索引，每张innodb表有且仅有一个，由存储引擎自动绑定：优先使用显式primary key，其次唯一非空列，最后隐式row_id；其叶子节点存储完整行数据，二级索引叶子节点仅存索引列值和主键值，查询需回表。
聚簇索引就是主键索引，且每张表只能有一个
InnoDB 表的聚簇索引不是你手动 CREATE INDEX 出来的，而是由存储引擎自动绑定的：它要么是显式定义的 PRIMARY KEY，要么是唯一非空列，最后 fallback 到隐藏的 row_id。这意味着你无法“删除聚簇索引”，只能改主键——而改主键会重建整张表。
常见错误现象：ALTER TABLE t DROP PRIMARY KEY 后发现表还能查，但执行 SHOW CREATE TABLE t 会看到 InnoDB 已悄悄用 row_id 当新聚簇索引；此时再加回主键，又得全表重建。
- 聚簇索引的叶子节点存的是完整行数据（含所有字段 + 隐藏列）
- 二级索引的叶子节点只存索引列值 + 对应主键值（不是物理地址）
- 没有显式主键时，
INSERT性能可能意外变差——因为row_id是单线程分配的，高并发插入会争抢
二级索引查询必须回表，除非满足覆盖索引
当你执行 SELECT name, age FROM user WHERE email = 'a@b.c'，而只有 email 上建了二级索引，InnoDB 就得先在 email 索引树里找到对应主键，再拿着主键去聚簇索引里捞出 name 和 age ——这就是“回表”。一次查询变成两次 B+ 树查找。
容易踩的坑：以为加了索引就一定快。如果 SELECT * 或查的字段没被索引包含，二级索引反而可能比全表扫描更慢（尤其结果集大时，回表随机 IO 开销巨大）。
- 覆盖索引能避免回表：比如
CREATE INDEX idx_email_name ON user(email, name)，查SELECT name FROM user WHERE email = ?就不用回表 - 联合索引顺序很重要：
email必须在前，否则无法走索引 -
ORDER BY或GROUP BY字段若不在索引中，即使走了二级索引，仍可能触发文件排序（Using filesort）
聚簇索引影响写入性能，二级索引影响读取路径
聚簇索引决定了数据在磁盘上的物理排列。用自增 id 当主键，新记录总追加到末尾页，写入高效；但用 UUID 或字符串主键，数据会频繁插入中间页，引发页分裂（page split），产生碎片、降低空间利用率、拖慢 INSERT 和 UPDATE。
二级索引不存数据，只存主键，所以它的更新成本低得多——但每个二级索引都会增加写放大：一次 INSERT 要同时写聚簇索引 + 所有二级索引的叶子节点。
- 高频写入场景下，二级索引越多，写入延迟越明显
-
UPDATE主键值会导致该行在聚簇索引中移动，并更新所有二级索引中对应的主键引用——这是禁止操作 - 删除大量数据后，聚簇索引页可能长期不回收，需
OPTIMIZE TABLE（本质是重建表）
MyISAM 没有聚簇索引，InnoDB 必有且仅有一个
别混淆引擎特性。MyISAM 的索引和数据分离存储，所有索引都是“非聚簇”的（叶子节点存的是行物理偏移量），因此它没有回表概念，但范围查询效率不如 InnoDB 聚簇索引。
如果你在迁移或排查慢查询时看到执行计划里出现 type: ALL 或 Extra: Using where，先确认是不是用了 MyISAM 表——那根本不存在聚簇索引优化这回事。
- InnoDB 表哪怕没定义主键，也一定有聚簇索引（隐式
row_id） - 试图用
ALTER TABLE ... ENGINE=InnoDB转换 MyISAM 表时，若原表无主键，InnoDB 会自动加row_id，但不会报错，容易忽略 - 跨引擎迁移后，原来在 MyISAM 上高效的
ORDER BY id可能在 InnoDB 上变慢——因为 MyISAM 的id不是聚簇键
EXPLAIN 输出里，但会在高峰期突然冒出来。
