聚簇索引即数据本身按主键组织在B+树叶子节点中，主键选择直接影响插入性能、页利用率、二级索引大小及IO效率；自增整数最优，UUID等长主键导致页分裂、碎片、缓存不友好和索引膨胀。
聚簇索引直接决定数据物理存储顺序
InnoDB 的聚簇索引不是“额外加的索引”，而是数据本身按主键值组织在 B+ 树叶子节点里。这意味着 INSERT 时新行往哪儿放，完全由主键值大小决定。如果主键是 AUTO_INCREMENT INT，新记录总追加到末尾；但若主键是 UUID() 或 VARCHAR(32) 字符串，值随机分布 → 插入位置跳变 → 频繁触发页分裂、随机 IO、索引碎片。
常见错误现象：SHOW ENGINE INNODB STATUS 中看到大量 Pages split；写入吞吐骤降；innodb_buffer_pool_pages_dirty 持续偏高。
- 自增整数主键：页内空间利用率稳定在 ~15/16KB，缓存友好
- UUID 字符串主键：单页可能只存 20–30 行（而非 300+），磁盘和内存开销翻倍
- 复合主键如
(tenant_id, order_id)：所有二级索引叶子节点都重复存这两个字段，极易突破innodb_page_size（默认 16KB）
二级索引体积和查询成本直接受主键长度影响
InnoDB 所有二级索引（INDEX）的叶子节点不存行地址，只存对应记录的主键值。主键就是所有索引的“共享成本”。主键越长，每个二级索引条目就越大，一页能存的索引项越少，IO 次数越多。
使用场景：一张订单表建了 idx_created_at、idx_status、idx_user_id 三个二级索引，主键从 BIGINT（8 字节）换成 VARCHAR(36)（平均 37 字节），这三个索引总空间可能膨胀 4–5 倍。
-
UUID_TO_BIN(UUID(), TRUE)比原生字符串 UUID 更紧凑（16 字节），且打乱时间位提升局部性 - 业务字段如身份证号、手机号做主键：必须评估是否真需要“语义即主键”——通常更优解是保留为
UNIQUE约束，另设自增id为主键 - 主键长度建议 ≤ 8 字节；超过 16 字节就要警惕二级索引和外键子表的冗余放大效应
更新主键等于全行重建，InnoDB 层面硬限制
修改主键值在 InnoDB 中不是字段赋值操作，而是逻辑删除 + 重新插入：聚簇索引要挪动数据行，所有二级索引都要同步更新对应主键指针。这不是慢，是“最重的 DML”之一。
容易踩的坑：UPDATE orders SET id = ? WHERE id = ? 不报错但极慢；ORM 如 MyBatis-Plus 默认禁用 @TableId 更新，但手写 SQL 时可能误写；ALGORITHM=INSTANT 对主键变更完全无效。
- 业务上需 ID 合并或迁移？走应用层逻辑标记（如
redirect_id字段 + 路由判断），而非UPDATE主键 - 外键引用主键时，子表索引也会继承全部主键列 —— 冗余被二次放大
- 哪怕只是
ALTER TABLE ... MODIFY COLUMN id VARCHAR(36) NOT NULL，只要涉及主键值重排，就可能锁表数分钟
没显式主键时 InnoDB 会偷偷用隐藏 ROW_ID
建表时既没写 PRIMARY KEY，也没有 NOT NULL UNIQUE 索引，InnoDB 就会生成一个 6 字节隐藏 ROW_ID 作为聚簇索引键。它不可见、不可查、无法排序，只在单个 INSERT 缓冲区内单调递增。
典型问题：高并发下 ROW_ID 冲突概率虽低，但线上真实发生过；EXPLAIN 看不到它，慢查询分析时误判“没走索引”；row 格式主从复制中，大事务删数据可能让备库夯住。
- 检查方法：
SELECT * FROM information_schema.INNODB_SYS_INDEXES WHERE TABLE_ID = (SELECT TABLE_ID FROM information_schema.INNODB_SYS_TABLES WHERE NAME = 'your_db/your_table') AND NAME = 'GEN_CLUST_INDEX' - 一旦发现
GEN_CLUST_INDEX，说明用了隐式主键，应立刻补ALTER TABLE ... ADD PRIMARY KEY (id) - 即使业务上真不需要主键语义，也请显式定义一个无业务含义的
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY
主键设计不是“选个唯一字段就行”，而是对整个表物理结构的长期承诺。最容易被忽略的一点是：你今天写的 CREATE TABLE 语句，决定了未来三年所有 INSERT、SELECT、UPDATE、DELETE 的底层 IO 模式和缓存行为。
