UUID 作主键导致页分裂严重，因其随机性使 InnoDB 聚簇索引频繁在页中间插入，触发页拆分、增加随机写和内存碎片；即便转为 BINARY(16) 或 MySQL 8.0+ 的 UUID_TO_BIN(uuid,1)（需启用时间戳左移），若未调整字节序仍难改善；雪花 ID 虽为递增 INT64，但时钟回拨、多实例未对齐或前端直传易致重复；真正缓解需结合有序主键（如自增 BIGINT 或时间前缀雪花 ID）与写入节奏优化。
UUID 作为主键为什么导致页分裂严重
因为 UUID 是随机生成的字符串（如 "550e8400-e29b-41d4-a716-446655440000"），插入时无法保证顺序，InnoDB 的聚簇索引会频繁在物理页中间位置插入新记录，触发页分裂（page split）——即一个满页被拆成两个半页，同时伴随大量磁盘随机写和内存碎片。
常见错误现象：innodb_page_splits 指标飙升、INSERT 延迟毛刺明显、SHOW ENGINE INNODB STATUS 中看到大量 "Pages split due to insert" 日志。
- 即使用了
UUID_SHORT()或UUID_TO_BIN()转二进制，只要没重排字节顺序（如将时间戳前置），仍是随机分布 - MySQL 8.0+ 的
UUID_TO_BIN(uuid, 1)可将时间戳左移，显著改善顺序性，但默认不开启 - 用
CHAR(36)存 UUID 比BINARY(16)多占一倍空间，间接加剧页分裂频率
雪花算法 ID 在 MySQL 中的实际落地陷阱
雪花算法生成的是 INT64 类型的递增（但非严格连续）整数，理论上比 UUID 更友好。但直接当主键用，仍可能因节点时钟回拨、多 DB 实例分库分表未对齐、或客户端生成 ID 未校验而引发问题。
使用场景：单机 MySQL 或已做严格时间同步的集群；若用在分库分表环境（如 ShardingSphere），必须确保 worker_id 和 datacenter_id 在全局唯一且稳定。
- MySQL 中推荐用
BIGINT UNSIGNED存储，避免负数比较异常 - 如果业务允许，建议由数据库代理层（如
vitess）或应用层统一生成，禁止前端直传 - 注意时钟回拨：哪怕只回拨 1ms，同一毫秒内生成的 ID 就可能重复，MySQL 报
ERROR 1062 (23000): Duplicate entry - 某些 Go/Java SDK 默认用系统毫秒时间戳，未做闰秒兼容，高精度场景下需额外处理
真正缓解页分裂的组合策略（不是选 A 或 B）
单纯换主键类型不够。页分裂是聚簇索引 + 写入模式 + 缓冲池管理共同作用的结果，得从存储结构和写入节奏协同优化。
- 强制主键有序：用
BIGINT自增（简单但丧失分布式能力）或带时间前缀的雪花 ID（如(timestamp） - 调整 InnoDB 页填充因子：
innodb_fill_factor = 70预留空间，减少分裂频次（但增加磁盘占用） - 关闭
innodb_autoinc_lock_mode = 2（交错模式），配合批量插入时用INSERT …… VALUES (……), (……), (……)减少自增锁争用 - 对高频插入表，考虑用
ROW_FORMAT=COMPRESSED+KEY_BLOCK_SIZE=8，降低单页数据量，变相提升页利用率
验证页分裂是否真被抑制的三个关键指标
别只看 QPS 或延迟，要盯住 InnoDB 底层行为指标，否则容易误判优化效果。
-
Innodb_buffer_pool_pages_misc突增 → 可能是页分裂后产生大量空闲页未及时回收 -
Innodb_page_splits下降但Innodb_pages_written上升 → 分裂减少，但写放大转移到其他路径（如二级索引维护） -
SELECT page_no, n_recs, data_size FROM information_schema.INNODB_BUFFER_PAGE WHERE TABLE_NAME = 'your_db/your_table' ORDER BY data_size DESC LIMIT 5→ 查看热点页实际记录密度，低于 60% 就值得警惕
页分裂不是“有或无”的问题，而是程度和代价的权衡。越想压低分裂率，越要接受更高的存储冗余或更复杂的 ID 生成链路——这点在设计初期就得认清楚。
