核心问题是uuid导致innodb频繁页分裂和随机i/o：其随机性使新记录插入位置无序，触发高频率页分裂、降低缓冲池命中率、增大二级索引体积，显著拖垮写入吞吐与查询性能。
MySQL 不建议用 UUID 做主键，核心问题不是“不能用”，而是它会强制 InnoDB 在写入时频繁触发页分裂和随机 I/O，直接拖垮写入吞吐与缓存效率。
UUID 导致 B+ 树叶子节点反复分裂
InnoDB 的聚簇索引要求数据行物理存储顺序必须和主键逻辑顺序一致。而 UUID（尤其是 v4）是完全随机生成的 128 位值，每次插入的新记录在 B+ 树中的位置毫无规律：
- 新
UUID可能落在任意已有数据页中间，而非末尾 - 当目标页已满（16KB），InnoDB 必须执行页分裂：把约一半记录挪到新页，再调整父节点指针
- 分裂不是偶发事件——高并发写入下，每秒数十次分裂很常见，且分裂后两页填充率都偏低（常低于 50%）
- 分裂过程需加 X 锁，容易引发锁等待甚至死锁，尤其在热点页（如最近高频插入区间）
对比 AUTO_INCREMENT：所有新行追加到最右叶子节点末尾，仅当该页满时才分裂一次，且新页立刻成为下一个插入目标，分裂频率极低。
随机 I/O 拖垮写入性能与 Buffer Pool 命中率
页分裂只是表象，背后是磁盘访问模式的根本恶化：
- 自增 ID 写入 → 顺序追加 → 操作系统预读生效 → 大量页被批量载入 Buffer Pool → 后续查询命中率高
-
UUID写入 → 插入位置跳跃 → 每次都可能触发独立的磁盘寻道 → 随机 I/O 增加 3–5 倍（实测 10w 行插入耗时高 2.7x） - Buffer Pool 中缓存的页彼此不连续，范围查询（如
WHERE id > ?）无法利用局部性原理，被迫多次跨页读取 - 二级索引也存储主键值，
UUID主键让每个二级索引条目膨胀至 16 字节（BINARY(16)）或 36 字节（CHAR(36)），进一步挤占 Buffer Pool 空间
即使转成 BINARY(16)，问题也没消失
有人尝试用 UUID_TO_BIN()（MySQL 8.0+）压缩存储，把 36 字符转为 16 字节二进制——这确实节省空间，但没解决根本问题：
- 二进制形式仍保持原
UUID的字典序（v4 就是纯随机字节），B+ 树插入位置依然无序 - 页分裂、随机 I/O、缓存污染等性能缺陷全部保留
- 唯一改善是二级索引体积缩小，但相比顺序性缺失带来的开销，这点收益微乎其微
真正有效的做法是改用时间前置的有序 UUID（如 v1/v6），或直接切到 Snowflake ——但要注意，Snowflake 也非银弹，它的“趋势递增”在多节点时仍有小范围逆序，仍比纯自增略差。
什么时候可以考虑 UUID？
只有同时满足以下条件时，才值得为 UUID 承担性能代价：
- 业务本质是多写入源（如分库分表、客户端直连、离线同步），且无法引入中心化 ID 生成服务
- 写入 QPS 很低（
- 已通过
innodb_page_size=4K或innodb_fill_factor=70等参数对分裂做保守调优
绝大多数 OLTP 场景里，你真正需要的不是“全局唯一”，而是“本地高效”。别让 UUID 的理论优势，掩盖了 B+ 树对顺序性的刚性依赖。
