应避免用uuid()直接作主键，因其随机性导致b+树频繁分裂；推荐uuid_to_bin(uuid(),1)存为binary(16)，或改用ulid、bigint auto_increment+业务id组合。
MySQL里用UUID()做主键会导致插入变慢
直接用 UUID() 生成的字符串作为主键，虽然全局唯一，但因为是随机十六进制字符串（如 '6a2e1f8c-4b5d-4e9a-b0c1-d2e3f4a5b6c7'），B+树索引会频繁分裂和页迁移，写入性能明显下降，尤其在高并发批量插入时更明显。
根本原因是标准 UUID 的前 8 位由时间戳低位、时钟序列和随机数混合生成，不具备单调递增性。MySQL 的聚簇索引按主键物理排序，随机值让新行总得插到中间位置，无法追加写。
- 避免用
UUID()直接作为PRIMARY KEY - 如果必须用 UUID，优先考虑
UUID_TO_BIN(UUID(), 1)存为BINARY(16)，节省空间且提升比较效率 - 不要用
VARCHAR(36)存原始 UUID 字符串——索引体积大、比较慢、内存占用高
用UUID_TO_BIN() + 时间前置的UUIDv1变体实现有序插入
MySQL 8.0+ 支持 UUID_TO_BIN()，配合手动构造“时间优先”的 UUID（类似 UUIDv1），能让高位字节反映时间顺序，从而在二进制排序中接近插入时间序。
典型做法是：用 UUID_SHORT() 或自定义函数生成时间戳高位 + 随机/节点信息的组合，再转成 BIN。但更稳妥的是用应用层生成——比如 Java 的 com.fasterxml.uuid.Generators.timeBasedGenerator()，或 Python 的 uuid1()，然后存为 BINARY(16)。
-
UUID_TO_BIN('123e4567-e89b-11d3-a456-426614174000', 1)中第二个参数1表示“交换时间字段”，这是实现排序有序的关键 - 建表时主键定义应为：
id BINARY(16) PRIMARY KEY DEFAULT (UUID_TO_BIN(UUID(), 1)) - 注意：MySQL 内置
UUID()仍是 v4，不带时间信息；UUID_TO_BIN(..., 1)只是对已有 UUID 重排字节，不能凭空造出时间序 —— 所以真正有序必须靠外部生成 v1/v7 或自定义时间前缀 UUID
替代方案：用ULID或KSUID比UUID更简单可靠
如果不想折腾 UUID 字节重排，又需要字符串主键的可读性和有序性，ULID（Universally Unique Lexicographically Sortable Identifier）是更优解。它由 48 位时间戳（毫秒级）+ 80 位随机数组成，字符串形式天然按字典序递增。
MySQL 本身不原生支持 ULID，但可通过函数模拟生成（需 8.0+）：
DELIMITER $$
CREATE FUNCTION gen_ulid() RETURNS CHAR(26)
READS SQL DATA
DETERMINISTIC
BEGIN
RETURN CONCAT(
LPAD(HEX(UNIX_TIMESTAMP(CURTIME(3)) * 1000), 12, '0'),
LPAD(HEX(FLOOR(RAND() * POW(2, 40))), 10, '0'),
LPAD(HEX(FLOOR(RAND() * POW(2, 40))), 10, '0')
);
END$$
DELIMITER ;
这个函数生成的字符串虽非严格 ULID 编码（缺少 Crockford Base32），但已具备时间前缀和字典序特性，且长度固定、无连字符，适合索引。
- ULID 字符串长度固定为 26，比 UUID 的 36 更短
- 直接用于
VARCHAR(26)主键即可，无需 BIN 转换，应用层也易解析 - 注意：上述函数中
RAND()在批量插入时可能重复，生产环境建议用存储过程结合SLEEP(0.001)或应用层生成
最务实的选择：用BIGINT AUTO_INCREMENT + 业务侧拼接唯一ID
多数场景下，“UUID 有序”是个伪需求。真正要的是“分布式唯一 + 可预测性能”。这时直接用 BIGINT UNSIGNED AUTO_INCREMENT 主键，搭配分库分表或雪花算法生成的逻辑 ID 作为业务唯一标识，反而更稳。
例如：主键用 id BIGINT PRIMARY KEY AUTO_INCREMENT，另设 trace_id VARCHAR(32) NOT NULL UNIQUE 存应用层生成的有序 UUID/ULID/KSUID，查询走 trace_id 索引，关联和排序用 id。
-
AUTO_INCREMENT在单实例下性能最优，且 MySQL 8.0 支持INVISIBLE列，可隐藏主键只对外暴露业务 ID - 如果必须跨库全局有序，可用
REPLACE INTO ... SELECT MAX(id)+1结合应用层缓存，或引入 Redis 原子计数器生成带时间戳的 long 类型 ID - 别为了“看着像 UUID”而牺牲写入吞吐和运维复杂度——很多团队踩坑后回退到
BIGINT+ 业务 ID 组合
实际落地时，最容易被忽略的是：有序性只在单机或单表维度有意义。一旦分库分表，或者用读写分离从库查数据，所谓“时间序”就只剩逻辑意义，物理顺序早已打散。这时候与其强求 UUID 有序，不如明确查询路径，用合适索引覆盖真实访问模式。
