MySQL 5.7 中 UUID() 不可作列默认值，须在存储过程中显式调用并赋值给变量（如 SELECT UUID() INTO v_id），再插入；避免在批量 INSERT 或循环中直接嵌入 UUID() 防优化器常量折叠导致重复；推荐配合触发器兜底或应用层压缩为 BINARY(16) 存储。
UUID()函数在 MySQL 5.7 中可用，但**不能直接用作列的默认值**（`DEFAULT UUID()` 在 5.7 不被支持），也不能在存储过程中通过简单赋值就“自动生效”——必须显式调用、显式插入或更新。你真正需要的是：怎么在存储过程里安全、不重复、可复用地生成并写入 UUID 主键。
MySQL 5.7 存储过程中调用 UUID() 必须显式赋值
MySQL 5.7 不允许在列定义中写 DEFAULT UUID()（会报错 Invalid default value for 'id'），所以即使你想“自动生成”，也得靠存储过程自己动手。UUID() 每次调用都返回新值，但它只是个表达式，不会自动绑定到变量或字段。
- 必须用
SET @id = UUID();或SELECT UUID() INTO @id;显式捕获 - 插入时必须写全字段：
INSERT INTO t (id, name) VALUES (@id, 'xxx');，不能省略id - 如果表已有数据且
id为NOT NULL，漏掉id字段会导致插入失败
避免在循环中误用 UUID() 导致重复值
常见错误：在 WHILE 循环里写 INSERT ... VALUES (UUID(), ...) —— 看似每次调用，但 MySQL 5.7 的查询优化器可能对函数做常量折叠（尤其在旧版本或特定 SQL 模式下），导致整批插入用同一个 UUID。
- ✅ 正确做法：每次循环内先调用一次
UUID()并存入局部变量，再插入 - ❌ 错误写法：
INSERT INTO t(id, name) SELECT UUID(), 'name' FROM DUAL;（在批量 INSERT 或子查询中风险高） - 实测建议：用
SELECT UUID() INTO v_id;（声明DECLARE v_id CHAR(36);）比直接嵌入更稳
主键冲突？UUID() 本身几乎不重复，但你要防人为覆盖
UUID() 是 v1/v4 混合实现（5.7 默认是 v1，含时间戳+MAC），理论上重复概率极低（远低于 2^(-122)）。但问题往往出在逻辑层：
- 如果你在存储过程中先
SELECT UUID() INTO v_id，又没立刻用，而是做了耗时操作（比如查表、调外部逻辑），再插入——中间若并发执行同一过程，仍可能撞上相同时间戳+MAC 组合（极小概率，但非零） - 更现实的风险：代码里误把
v_id赋给多个INSERT，或在异常分支里重复用了同一个变量 - 无索引/无主键的表上盲目
INSERT ... ON DUPLICATE KEY UPDATE会静默失败——务必确认表真有PRIMARY KEY (id)
想省事？用触发器补位，但要注意兼容性
MySQL 5.7 支持 BEFORE INSERT 触发器，可以兜底生成 UUID，绕过应用层疏漏：
DELIMITER $$
CREATE TRIGGER t_before_insert BEFORE INSERT ON my_table
FOR EACH ROW
BEGIN
IF NEW.id IS NULL OR NEW.id = '' THEN
SET NEW.id = UUID();
END IF;
END$$
DELIMITER ;
- 这个触发器只在
NEW.id为空时才生成，不影响你主动传值的场景 - 注意：如果表结构里
id是NOT NULL但没默认值，而你INSERT INTO t(name) VALUES('x')，触发器能救；但如果id允许NULL，又没触发器，就会存进去一个NULL，后续主键约束失效 - 触发器无法解决跨事务并发下的“先查后插”竞争，它只管单条语句
真正容易被忽略的一点：MySQL 5.7 的 UUID() 返回的是带连字符的 36 字符串（如 550e8400-e29b-41d4-a716-446655440000），如果你后续要用 UNHEX(REPLACE(...)) 压缩存储，必须在存储过程里同步处理，不能指望“后面再转”——因为字符串形式一旦入库，二进制转换就失去时间序优势，也浪费空间。
