mysql不建议用uuid做聚簇索引主键，根本原因是innodb要求主键有序插入以避免页分裂，而v4 uuid完全随机，导致新记录大概率插入数据页中间，页满即触发确定性页分裂，引发i/o激增、碎片增长和缓存命中率下降。
MySQL集群中不建议用UUID做聚簇索引主键，根本原因不是“分布式”本身，而是InnoDB的聚簇索引机制与UUID的随机性之间存在不可调和的冲突——每次插入都大概率触发页分裂，写入性能断崖式下跌，且无法靠加机器或分库分表掩盖。
为什么UUID插入必然引发高频页分裂
InnoDB聚簇索引要求数据物理存储顺序 = 主键值排序顺序。UUID()生成的是v4随机字节序列（如550e8400-e29b-41d4-a716-446655440000），其二进制比较无时间局部性。新记录插入时需二分查找位置，结果90%以上落在已有数据页中间而非末尾。一旦目标页已满（默认填充率约15/16KB），InnoDB必须执行页分裂：搬走约一半记录、分配新页、更新父节点指针、写doublewrite buffer。
- 这不是偶发抖动，是确定性开销：实测每插入1000行UUID，平均触发1.7次页分裂
-
SHOW ENGINE INNODB STATUS里频繁出现Pages split due to insert -
SHOW TABLE STATUS中Data_free持续增长，常达实际数据体积的30%以上 - 分裂后原页利用率暴跌至50%以下，形成不可逆的索引碎片
BINARY(16)或UUID_TO_BIN()并不能解决问题
把CHAR(36)改成BINARY(16)只省了20字节存储，但没动“随机性”这个命门。InnoDB比较BINARY值仍是逐字节比对，而标准UUID前4字节（时间低位）并不单调递增，插入位置依然不可预测。
-
UUID_TO_BIN(uuid, 0)（即不带swap_flag）只是压缩编码，字节序未重排，仍是随机序 - 必须用
UUID_TO_BIN(uuid, 1)才将时间戳高位左移，实现近似有序；但仅限MySQL 8.0+ - 即使用了
UUID_TO_BIN(uuid, 1)，同一毫秒内生成的多个UUID后缀仍随机，高并发写入下仍会集中撑满单页 - 若字段类型仍是
CHAR(36)，转换白做——BIN_TO_UUID()查出来的还是乱序字符串
自增ID在集群中真就不可用？
很多人误以为“集群=必须UUID”，其实错把ID生成逻辑和主键设计混为一谈。自增ID的缺陷是单点生成，但解决方案成熟：
- 各实例配置不同
auto_increment_offset和auto_increment_increment，例如5台DB设offset为1/2/3/4/5、increment=5，天然避免冲突 - Proxy层（如Vitess、ShardingSphere）统一分发ID，后端仍用自增，兼顾性能与全局唯一
- 业务层用雪花ID生成
BIGINT，存入BIGINT UNSIGNED字段——注意校准时钟回拨，worker_id必须全局唯一 - 完全回避主键唯一性问题：用
CREATE TABLE ... (id BIGINT PRIMARY KEY, logical_id VARCHAR(36))，UUID存为普通字段，主键保持自增
ORDER BY id和范围查询会彻底失效
当主键是UUID时，SELECT * FROM t ORDER BY id LIMIT 10几乎必然退化为全表扫描。因为B+树叶子节点物理顺序与主键逻辑顺序严重脱钩，InnoDB无法利用双向链表跳跃遍历，必须逐页检查所有叶子节点才能凑够10条最小值。
- 自增ID下该查询通常只需读1–2个连续页；UUID下可能扫几十甚至上百页
- 二级索引叶子节点存的是主键值，
BINARY(16)让单页索引项减少约45%，树高增加，JOIN和多条件查询I/O成本翻倍 - Buffer Pool缓存的页彼此离散，范围查询无法触发操作系统预读，随机I/O增加3–5倍
- 监控上表现为
innodb_buffer_pool_reads飙升、磁盘IO使用率长期>90%
真正难处理的不是“怎么换主键”，而是现有UUID主键表的数据迁移路径——页分裂造成的碎片不会因换主键自动修复，OPTIMIZE TABLE或ALTER TABLE ... FORCE会锁表，且重建索引时若仍用UUID，碎片照旧。线上系统改主键前，务必先压测页分裂率和Buffer Pool污染程度。
