mysql 5.7及更早版本不支持uuid()作默认值，因属非确定性函数，会报错“invalid default value”；8.0.13+虽支持default(uuid())但需char(36)字段且括号不可省，否则截断或失效。
不能直接用 UUID() 函数作为主键列的默认值（MySQL 8.0.13 之前不支持），且 UUID 作为主键需显式插入或用触发器/应用层生成，否则会报错或存空字符串。
为什么 DEFAULT UUID() 在旧版本 MySQL 中无效
MySQL 5.7 及更早版本不支持将 UUID() 这类非确定性函数设为列的 DEFAULT 值。尝试执行类似语句会直接报错：ERROR 1064 (42000): Invalid default value for 'id'。
即使在 MySQL 8.0.13+ 支持函数默认值，UUID() 返回的是 36 字符的字符串（含连字符），必须配合 VARCHAR(36) 或 CHAR(36) 使用；若字段类型不匹配（比如用了 CHAR(32)），插入时会被截断，导致重复或损坏。
- 必须用
CHAR(36)存储标准 UUID，CHAR(32)需手动去连字符（如用REPLACE(UUID(), '-', '')） - 主键列不能设为
NULL，所以定义时要加NOT NULL - 不建议用
VARCHAR—— 固定长度的CHAR在索引和比较时更稳定
正确建表方式：显式插入 + 主键约束
最稳妥的做法是把 UUID 生成逻辑交给应用层或 SQL 插入语句本身，数据库只负责校验唯一性和非空：
CREATE TABLE users ( id CHAR(36) PRIMARY KEY, name VARCHAR(50), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
插入时必须显式调用 UUID()：
INSERT INTO users (id, name) VALUES (UUID(), 'Alice');
如果漏写 id 字段，MySQL 会报错：ERROR 1364 (HY000): Field 'id' doesn't have a default value —— 这反而是你想要的安全行为。
- 不要依赖客户端自动生成空字符串或 NULL 来“占位”，那会导致主键冲突或违反 NOT NULL
- 如果用 ORM（如 Laravel Eloquent、Django），确认其 UUID 生成是否调用的是
UUID()而非本地伪随机字符串 - 批量插入时，每个
UUID()调用都是独立执行的，不会重复（概率极低，但理论上存在，靠主键约束兜底）
替代方案：UUID_SHORT() 不是 UUID，别混用
UUID_SHORT() 返回的是 BIGINT UNSIGNED 整数，不是标准 UUID 格式。它和 UUID() 完全不兼容：
- 存储类型必须是
BIGINT UNSIGNED，用VARCHAR或CHAR存会高位截断 - 依赖正确的
server_id配置（1–255），否则集群中极易重复 - 不适用于需要标准 UUID 字符串的场景（如 API ID、OAuth token、前端路由）
- 主从复制若用 STATEMENT 模式，
UUID_SHORT()在从库重放时值不同，引发数据不一致
如果你真需要整数型全局唯一 ID，优先考虑 auto_increment + 分库分表路由，或 Snowflake 类算法，而不是硬套 UUID_SHORT()。
性能与索引影响：UUID 主键不是免费的
UUID 作为主键会显著影响 B+Tree 索引效率：
- 插入随机性高 → 页面分裂频繁 → 写放大严重
- 索引体积大（36 字节 vs
BIGINT的 8 字节）→ 缓存命中率下降 - 范围查询（如
BETWEEN、ORDER BY id）基本失效，因为 UUID 无时间/顺序含义 - 若业务允许，可用
UUID_TO_BIN(UUID(), 1)（MySQL 8.0+）转为 16 字节二进制存储，并设为BINARY(16)主键，能减小约 55% 索引空间，但依然无法解决插入无序问题
真正关键的一点：UUID 主键的“全局唯一”代价是写性能和存储开销，除非你明确需要跨库/跨服务合并数据，否则大多数单体应用用 AUTO_INCREMENT 更实在。
