UUID()返回36字符字符串（如'6b2e16a0-394c-11ef-9f85-00155d012345'），必须配CHAR(36)字段，不可直接用于INT/BIGINT主键；虽可作主键但因随机性导致B+树频繁分裂、插入慢3–5倍，仅适用于低频插入或需兼容外部UUID格式的场景。
MySQL UUID() 函数返回什么格式，能直接当主键用吗
UUID() 返回的是 36 字符的字符串（形如 '6b2e16a0-394c-11ef-9f85-00155d012345'），含 4 个短横线和小写字母。它本身不是数字，不能作为 INT 或 BIGINT 主键；若想用，字段类型必须是 VARCHAR(36) 或更优的 CHAR(36)（定长，索引效率略高）。
常见错误是建表时写成：id INT PRIMARY KEY DEFAULT UUID() —— 这会报错，因为 UUID() 返回字符串，且 MySQL 5.7 及以前不支持函数作为列默认值（8.0.13+ 才支持函数默认值，但仍要求类型匹配）。
- MySQL 5.7 及更早：只能在
INSERT语句中显式调用UUID() - MySQL 8.0.13+：可定义
id CHAR(36) DEFAULT (UUID())（注意括号，这是生成列语法） - 别用
TEXT存 UUID：无法建主键、索引效率差、排序异常
为什么不用 UUID_SHORT() 替代 UUID()
UUID_SHORT() 返回的是无符号整数（BIGINT UNSIGNED），看起来“更适合作主键”——但它依赖服务器启动时间 + 服务器 ID + 每秒计数器，**不是全局唯一**：多实例部署时若未配置唯一 server_id，极易冲突；重启频繁或高并发下也可能重复（尤其在从库上执行时行为不稳定）。
真正需要跨库/分片/离线生成唯一 ID 的场景，UUID() 是更稳妥的选择，哪怕牺牲一点存储和索引性能。
-
UUID_SHORT()要求server_id全局唯一，且不能为 0 或 1（MySQL 官方文档明确警告） - 它的值是单调递增的，但只在单机内成立；跨节点无序，对范围查询和聚簇索引（InnoDB 主键）不友好
- 如果业务已用
UUID()生成 ID 并同步到其他系统（如 Elasticsearch、Redis），换UUID_SHORT()会导致 ID 格式不一致
插入时怎么安全调用 UUID()，避免应用层重复生成
最简方式是在 INSERT 语句里直接写 UUID()，由 MySQL 服务端生成，确保原子性和唯一性：
INSERT INTO users (id, name, email) VALUES (UUID(), 'Alice', 'a@example.com');
不要在应用代码里先调用一次 UUID()，再拼 SQL 插入——这多一次网络往返，且如果中间出错（如连接中断、事务回滚），ID 就浪费了，还可能因重试逻辑导致重复插入风险。
- 使用预处理语句（Prepared Statement）时，仍推荐服务端生成：
INSERT INTO t(id, ...) VALUES (UUID(), ...)，而非绑定参数传入 UUID 字符串 - 如果必须由应用生成（例如要提前记录日志或做幂等校验），请确认使用的是 RFC 4122 版本 4 的 UUID（PHP
ramsey/uuid、Pythonuuid.uuid4()、Javajava.util.UUID.randomUUID()均符合） - 避免用
MD5(NOW() + RAND())等自造方案：碰撞概率远高于标准 UUID，且不可读、难调试
UUID() 作主键对 InnoDB 性能有哪些实际影响
InnoDB 的聚簇索引把数据按主键物理排序。用随机字符串作主键，会导致新记录几乎总是插入到索引页中间或任意位置，引发大量页分裂、内存碎片和磁盘随机写，写入吞吐明显下降（相比自增 INT 可能低 3–5 倍）。
这不是理论问题：线上批量导入百万级用户时，UUID 主键表的 INSERT 速度常卡在 500–1000 行/秒，而自增主键可达 5000+ 行/秒。
- 解决方案之一：加一个
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY，另设uuid CHAR(36) UNIQUE NOT NULL，业务用uuid对外暴露，内部关联用id - 若坚持用
UUID当主键，至少用CHAR(36)而非VARCHAR(36)，减少变长开销；并考虑定期OPTIMIZE TABLE - MySQL 8.0+ 支持
UUID_TO_BIN(UUID(), 1)将 UUID 转为 16 字节二进制（保留顺序性），配合BINARY(16)字段可提升索引效率，但需应用层统一转换逻辑
