UUID()返回36字符字符串，需VARCHAR(36)存储，索引体积大、写入慢；UUID_SHORT()返回BIGINT UNSIGNED整数，依赖server_id，值=(server_id & 255)。
UUID() 生成的是字符串，不是整数
很多人误以为 UUID() 返回的是可直接存进 BIGINT 的数字，其实它返回的是类似 "c7f5a8e0-9a6b-11eb-bc58-0242ac130003" 的 36 字符字符串（含 4 个连字符）。直接往 INT 或 BIGINT 字段里插会报错：ERROR 1366 (HY000): Incorrect integer value。
- 必须配
VARCHAR(36)或CHAR(36)字段，索引体积大、比较慢、缓存效率低 - 值本身无序，写入时导致 B+ 树频繁页分裂，实测百万插入比自增慢 3–5 倍
- 仅适合低频表（如配置表）、或必须对外暴露标准 UUID 格式的场景（比如 API 返回 ID 需和前端约定一致）
UUID_SHORT() 返回的是 BIGINT UNSIGNED 整数
UUID_SHORT() 看名字像“短字符串”，实际返回的是 64 位无符号整数（0 到 18446744073709551615），不是字符串，更不是 VARCHAR。
- 字段类型必须定义为
BIGINT UNSIGNED，写成BIGINT（有符号）或INT都会溢出，报错：ERROR 1264 (22003): Out of range value for column 'id' - 依赖
server_id：值 =(server_id & 255) ，所以 <code>server_id必须非零且全局唯一 - 多实例部署时，漏配
server_id或重复设置，就会产生冲突 ID —— 这是线上最常踩的坑
高并发写入时 UUID() 会拖慢整个表
主键即聚簇索引，InnoDB 按主键顺序物理存储数据。UUID() 值随机分布，新记录大概率插在中间页而非末尾，触发大量页分裂和磁盘 I/O。
- 订单、日志、消息类高频写入表，绝对不要用
UUID()当主键 - 实测
COUNT(*)性能差距极大：UUID 表耗时 6.11s，UUID_SHORT()表仅 0.82s - 即使加了二级索引，主键乱序仍会放大 Buffer Pool 压力，影响其他查询响应
别被名字误导：UUID_SHORT 不是“短 UUID 字符串”
这个名字极易引发误解。它既不输出字符串，也不兼容标准 UUID 格式，更不是 UUID() 的精简版。
- 它本质是一个带时间戳和 server_id 的分布式序列生成器，适合当主键用
- 如果你需要的是
"xxxx-xxxx-xxxx"这种格式，就别用UUID_SHORT()，老实用UUID()+VARCHAR(36) - 真正要兼顾性能与格式的折中方案：应用层生成 v4 UUID 存字符串，同时额外加一列
bigint unsigned作内部主键（但需额外维护）
server_id 配错、字段类型没加 UNSIGNED、误以为它能替代 UUID 字符串——这三个点，占了线上 UUID 相关问题的八成以上。
