是的，MySQL UUID()函数生成的是RFC 4122 v1标准UUID，理论全局唯一，但依赖时间戳+MAC/随机数，超限或MAC重复等边界条件下存在碰撞风险；且无序、占空间大、导致索引性能差。
MySQL里UUID()函数返回的是不是真正全局唯一？
是的，UUID() 生成的是标准 RFC 4122 版本 1 的 UUID（基于时间戳 + MAC 地址 + 随机数），在正常网络和硬件条件下，重复概率可视为零。但要注意：它不保证单调递增，也不适合做主键索引的首选——因为随机字符串会导致大量页分裂和插入性能下降。
直接用UUID()当主键会遇到什么问题？
常见现象：INSERT 变慢、SELECT ... ORDER BY id DESC 慢、二级索引体积膨胀、InnoDB 聚簇索引碎片严重。
-
UUID()是 36 字符的字符串（含 4 个-），比BIGINT占用空间大 4–5 倍 - InnoDB 默认按主键物理排序，随机 UUID 导致新行总插入到中间位置，频繁触发页分裂
- 如果业务需要按“时间先后”查最新记录，
UUID()本身不含时间序，得额外加created_at字段并建联合索引
怎么存更高效？去掉横杠并转成BINARY(16)
UUID 字符串中 4 个 - 是纯展示用，移除后长度从 36 降到 32；再用 UNHEX() 转成二进制，存储只需 BINARY(16)，查询和索引效率明显提升。
建表示例：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
CREATE TABLE orders ( id BINARY(16) PRIMARY KEY DEFAULT (UNHEX(REPLACE(UUID(), '-', ''))), user_id INT, amount DECIMAL(10,2), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
插入时不用显式赋值，InnoDB 会自动调用默认表达式；读取时可用 HEX(id) 或 UUID_TO_BIN()（MySQL 8.0+）还原可读格式。
MySQL 8.0+ 推荐用UUID_TO_BIN()配合UUID()生成紧凑ID
相比手写 REPLACE + UNHEX，UUID_TO_BIN() 更安全：它默认开启 swap_flag = 1，把时间戳部分前置，让生成的二进制值具备一定时间局部性，缓解聚簇索引随机写问题。
- 插入用：
UUID_TO_BIN(UUID(), 1) - 查询还原用：
BIN_TO_UUID(id, 1) - 注意：
UUID_TO_BIN()的第二个参数必须和存入时一致，否则还原错乱
真正容易被忽略的是：如果你用 ORM（比如 Laravel Eloquent 或 Django），默认不支持这种二进制 UUID 主键的自动填充和序列化，得手动覆盖模型的 getKeyType() 或字段转换逻辑——否则查出来是个空字节串或报错。
