uuid() 不适合高并发写入，因其随机性导致b+树频繁页分裂、i/o激增、插入慢3–5倍、count(*)慢近8倍；仅适用于低频插入或必须兼容外部uuid格式的场景。
UUID_SHORT() 适合高并发写入、需要整型主键、且能控制 server_id 的场景；UUID() 仅适用于低频插入、不关心索引碎片、或必须兼容外部系统 UUID 格式的场合。
UUID() 写入时会导致 B+ 树频繁分裂
每次 UUID() 生成的字符串（如 "c7f5a8e0-9a6b-11eb-bc58-0242ac130003"）是时间+MAC+随机组合，但整体无序。InnoDB 主键即聚簇索引，新值大概率插在中间页而非末尾，触发页分裂和大量磁盘 I/O。
实测百万级插入：UUID() 比 auto_increment 慢 3–5 倍，比 UUID_SHORT() 慢 2 倍以上；查询 COUNT(*) 也慢近 8 倍（6.11s vs 0.82s）。
- 不要在日志表、订单表等高频写入表上用
UUID()当主键 - 如果已有业务强依赖 UUID 字符串格式（比如前端要直接展示或传给第三方 API），再考虑它，否则纯属自找麻烦
-
UUID()返回值长度固定 36 字节（含连字符），VARCHAR(36)至少占 37 字节（含长度字节），索引体积大、缓存利用率低
UUID_SHORT() 要求 server_id 必须唯一且非零
UUID_SHORT() 本质是 (server_id ，其中 <code>counter 每秒重置，最大支持约 1677 万次/秒（2^24）。一旦 server_id 为 0 或重复，生成值就可能冲突。
检查方式：SELECT @@server_id;；设为非零唯一值：SET GLOBAL server_id = 123;（需写入 my.cnf 并重启才持久）。
- 多实例部署时，每个 MySQL 实例必须配不同
server_id，否则UUID_SHORT()全局不唯一 - 主从架构下，
server_id已用于复制标识，通常已设好——但新搭建集群常漏配 - 重启 MySQL 后
counter归零，但因含时间戳和server_id，仍可保证全局唯一；除非单秒内超 16M 插入（现实中几乎不会）
UUID_SHORT() 主键字段类型必须是 BIGINT UNSIGNED
UUID_SHORT() 返回的是 64 位无符号整数（范围 0–18446744073709551615），若字段定义为 BIGINT SIGNED 或 INT，会截断或溢出报错。
建表示例：CREATE TABLE logs (id BIGINT UNSIGNED PRIMARY KEY, msg TEXT);
- 字段类型错配会导致插入失败，错误类似：
ERROR 1264 (22003): Out of range value for column 'id' - 不能用
INT或INT UNSIGNED（最大仅 4294967295），UUID_SHORT()值远超此范围 - 虽然叫 “short”，但它不是“短 UUID 字符串”，而是“短整型 UUID”——别被名字误导
真正需要 UUID 字符串时，别在 MySQL 里拼接
有些业务要求主键是标准 UUID 格式（如 "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"），又想避免 UUID() 的性能问题，这时别用 MySQL 拼：CONCAT(HEX(RANDOM_BYTES(4)), '-', ...)——既难维护又慢。
更可靠的做法：应用层生成（如 Java 的 UUID.randomUUID() 或 Python 的 uuid.uuid4()），然后作为参数传入 INSERT。
- MySQL 的
UUID()函数在事务中多次调用返回不同值，无法复现；而应用层生成可精确控制时机和值 - 若必须数据库侧生成，且要字符串格式，优先考虑
UUID_SHORT()+ 应用层转格式（极少见） - 注意：MySQL 8.0+ 支持
UUID_TO_BIN()和UUID_FROM_BIN()，可压缩存储，但仍是字符串逻辑，没解决排序问题
UUID_SHORT() 是“UUID 的精简版”，其实它和标准 UUID 协议无关，只是个带时间戳的分布式整数 ID——它不兼容任何 UUID 解析库，也不能被当作 UUID 使用。选它，就是选整型主键的折中方案，而不是在 UUID 生态里找优化。
