为什么MySQL InnoDB引擎的聚簇索引对主键性能影响巨大？

InnoDB聚簇索引即主键，决定数据物理存储顺序；无主键时自动生成不可见、不唯一、不递增的6字节ROW_ID，易引发高并发冲突、慢查询误判及备库夯住；自增整数主键可避免页分裂、减少随机IO，而UUID或复合主键会导致索引膨胀、性能下降；更新主键等于删行+插行，须严格禁止。

聚簇索引就是主键，主键就是物理存储顺序

InnoDB 的聚簇索引不是“基于主键的索引”，它直接把主键值作为数据页组织的键。这意味着 SELECT * FROM t WHERE id = 123 不是“查索引再取数据”，而是顺着 B+ 树一路落到叶子页——那一页里就存着整行数据。没主键？InnoDB 会悄悄用隐藏 ROW_ID，但这个值不可见、不递增、不唯一，EXPLAIN 看不到，慢查询分析时你根本不知道自己在扫什么。

自增整数主键避免页分裂，UUID 主键引发随机 IO

新记录插入位置由主键值决定：

• AUTO_INCREMENT INT → 总追加到 B+ 树末尾 → 单页写满再开新页，几乎不触发页分裂

• VARCHAR(36) 存 UUID → 值完全随机 → 新行可能插进任意中间页 → 页频繁分裂 + 缓冲池缓存失效 + 磁盘随机读

• 复合主键如 (tenant_id, order_id) → 所有二级索引叶子节点都重复存这两个字段 → 索引体积翻倍，innodb_page_size（默认 16KB）更容易被撑爆

更新主键等于删行+插行，所有二级索引全重算

执行 UPDATE t SET id = 456 WHERE id = 123 时，InnoDB 不是改一个字段：它先按旧 id 定位并删除整行，再用新 id 重新构造聚簇索引位置，最后把所有二级索引里的旧主键值批量替换成新值。这操作会：

• 触发聚簇索引页分裂或合并

• 强制重刷所有二级索引的对应叶子节点

• 在大表上可能锁住整页甚至整范围，阻塞并发

没主键时 InnoDB 的隐藏 ROW_ID 是个排查黑洞

建表时既没写 PRIMARY KEY，也没定义 NOT NULL UNIQUE 索引，InnoDB 就生成 6 字节隐藏 ROW_ID。问题在于：

• 它只在单个 INSERT buffer 内单调递增，跨线程/事务不保证顺序

• 高并发下极小概率冲突（线上真实发生过备库夯住）

• 无法用于 ORDER BY、分页、外键，也不能被 SELECT 查出

• 主从复制用 row 模式时，DELETE 大事务可能让备库卡在解析隐藏键上

真正难处理的不是“要不要主键”，而是主键一旦选定，就绑定了整个表的物理结构和所有索引的成本。换主键不是 ALTER TABLE 加个字段的事，是重建聚簇索引 + 所有二级索引 + 重写全部数据页。