主键不必是自增整数但强烈推荐；非自增主键（如UUID、字符串）易引发页分裂、随机IO和索引碎片，增大二级索引体积并降低缓存效率；更新主键等于全行重建，必须禁止；无显式主键时InnoDB会生成隐藏ROW_ID，存在冲突与排查风险。
主键必须是自增整数？不，但强烈推荐
InnoDB 表的主键直接决定聚簇索引的物理存储顺序。如果主键不是 AUTO_INCREMENT 整数（比如用 VARCHAR(32) 存 UUID），插入新行时很可能引发页分裂、随机 IO 和索引碎片——尤其在高并发写入场景下，性能下降肉眼可见。
- 自增整数主键让新记录总追加到索引末尾，写入稳定、缓存友好
- UUID 或业务字段（如身份证号、手机号）做主键：值无序 → 数据页频繁重排 →
INSERT变慢，SELECT ... ORDER BY id也未必快（因为物理顺序 ≠ 逻辑顺序） - 若必须用 UUID，优先选
UUID_TO_BIN(UUID(), TRUE)转为二进制并打乱时间位，比原生字符串 UUID 更紧凑、局部性更好
为什么不能用字符串或复合字段当主键
InnoDB 的聚簇索引把主键值“复制”到所有二级索引的叶子节点里。主键越长，二级索引占用空间越大，缓存效率越低，查询扫描成本越高。
- 一个
VARCHAR(64)主键 → 所有INDEX的每条索引记录都多存 64 字节（甚至更多，含长度前缀） - 复合主键（如
(tenant_id, order_id)）会让每个二级索引条目都带上这两个字段，极易突破innodb_page_size限制，触发额外 IO - 主键被外键引用时，子表索引也会继承全部主键列 —— 冗余放大效应非常明显
主键更新等于全行重建，务必禁止
InnoDB 中修改主键值，本质是删除旧行 + 插入新行：聚簇索引要挪动数据，所有二级索引都要同步更新指针。这不是“改个字段”，而是最重的 DML 操作之一。
- ORM 如 MyBatis-Plus 默认不会更新
@TableId字段，但手写UPDATE语句时可能误写SET id = ?，MySQL 不报错但执行极慢 - 业务上需要“迁移 ID”或“合并记录”？应走逻辑标记（如
redirect_id）+ 应用层路由，而非直接 UPDATE 主键 - 建表时加
ALGORITHM=INSTANT也无法绕过该限制 —— 这是存储引擎层面的硬约束
没有显式主键时，InnoDB 会偷偷干啥
如果你建表时完全没定义 PRIMARY KEY，且没有 NOT NULL UNIQUE 索引，InnoDB 会自动生成一个隐藏的 6 字节 ROW_ID 作为聚簇索引键 —— 它不可见、不可查、无法用于关联，还可能在高并发下产生冲突（虽然概率极低）。
- 这个隐藏
ROW_ID不保证全局递增，只在单个 INSERT 缓冲区内单调 - 无法被
EXPLAIN显示，排查慢查询时容易误判索引使用情况 - 只要定义了任一
NOT NULL UNIQUE键，InnoDB 就优先用它当聚簇索引 —— 所以宁可加个无意义的id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY，也别裸奔
