uuid无序写入破坏innodb聚簇索引物理连续性，导致频繁页分裂、缓存效率暴跌及order by id全表扫描；binary(16)仅省空间不改随机性；真正有效方案是mysql 8.0+配合uuid_to_bin(...,1)与v1/v7或uuid_short()生成有序id。
UUID无序写入直接破坏InnoDB聚簇索引的物理连续性
InnoDB的聚簇索引不是“逻辑有序”，而是“数据就长在主键B+树叶子节点里”——主键值决定行数据在磁盘上的落盘位置。UUID()生成的字符串（如550e8400-e29b-41d4-a716-446655440000）是纯随机字节序列，每次插入都得二分查找B+树中“该插哪一页”，结果大概率落在已有页中间，而非末尾。
这导致：
- 目标页若已填充80%以上，新记录一来就触发Page Split
- 原页约一半数据被挪到新建页，父节点指针重连
- 分裂后两页都半空（实测常低于50%利用率），且物理位置不连续
- SHOW TABLE STATUS里的Data_free会持续上涨，但这只是冰山一角；页内稀疏（比如16KB页只存30条UUID行）根本不会体现在该字段里
BINARY(16)不能解决页分裂，只省了空间
很多人把CHAR(36)改成BINARY(16)就以为“优化完了”，其实只是把存储从36字节压到16字节，随机性一点没变。
原因在于：
- BINARY(16)比较的是原始字节顺序，而标准UUIDv4的16字节本身就是时间戳低位+随机段混排，高位字节毫无时间规律
- 两个UUID：前8字节分别是0x1a2b3c4d...和0x6d5c5a5e...，光看首字节就决定了它们在B+树里相隔十万八千里
- 二级索引叶子节点存的也是这个16字节主键值，所以索引体积虽小了，但回表时仍要按随机地址跳着读数据页，Buffer Pool缓存效率暴跌
真正有效的有序方案必须重排时间戳高位
MySQL 8.0+的UUID_TO_BIN(uuid, 1)之所以有用，是因为第二个参数1启用了字节交换（swap_flag），把UUIDv1/v7中原本藏在中间的时间戳高位提到最前面——这样二进制比较时，新生成的ID天然接近递增。
但要注意：
- UUID()函数本身仍是v4，不带时间信息；UUID_TO_BIN(UUID(), 1)对v4做swap只是白忙活，排序还是随机的
- 必须配合应用层生成v1/v7，或用UUID_SHORT()（单机有序，8字节整型）
- 即便用了UUID_TO_BIN(..., 1)，同一毫秒内高并发生成的多个ID后缀仍是随机的，仍可能挤爆单页引发分裂（测试显示页分裂率比自增ID仍高3~5倍）
ORDER BY id变成全表扫描不是SQL写错了，是物理存储决定的
当主键是UUID时，SELECT * FROM t ORDER BY id LIMIT 10几乎必然走全表扫描。这不是优化器笨，而是B+树叶子节点之间虽然有双向链表，但物理上完全打散——InnoDB没法从“最小id所在页”开始顺序往后读几页就凑够10条，它得遍历大量页才能收集到逻辑上最小的那10个值。
对比自增ID：
- 最小id一定在最左页，最大id一定在最右页，范围查询、分页、MIN()/MAX()都极快
- UUID主键下，哪怕加了WHERE id > BIN_TO_UUID(...)，也只能靠索引定位起始点，后续仍要跨页跳跃读取，I/O成本差一个数量级
- 这种代价不是一次性的，而是随着写入量增长持续恶化：Buffer Pool里缓存的页彼此不连续，局部性原理彻底失效
页分裂不是“偶尔卡一下”，它是持续写入过程中每一条UUID记录都在悄悄放大的系统性损耗。真正难处理的不是第一次重建表，而是如何让后续每一笔INSERT都不再制造新碎片——这要求从ID生成源头就控制顺序，而不是靠OPTIMIZE TABLE事后补救。
