不靠谱，UUID()生成的订单号长度36字符、含横线、无序、不易读，易被截断，仅适合主键而非业务订单号；批量插入时虽唯一性高，但微秒级精度下高并发仍存极低碰撞风险，需结合REPLACE、截取或日期前缀优化。
MySQL里用UUID()生成订单号真的靠谱吗
不靠谱，直接用UUID()当订单号会出问题：长度太长（36字符）、含横线、无序、不易读，还可能被前端或下游系统截断。它适合做主键，不适合做业务订单号。
批量插入时如何确保UUID不重复且可读性可控
MySQL的UUID()本身是全局唯一的，但批量执行时若在同一个事务里多次调用，仍可能因时间精度限制（微秒级）导致碰撞——虽概率极低，但在高并发订单场景下不能赌。更稳妥的做法是组合使用：
- 用
REPLACE(UUID(), '-', '')去掉横线，得到32位纯数字+字母字符串 - 截取前16位（
LEFT(REPLACE(UUID(), '-', ''), 16)），兼顾长度与冲突率（实测百万级插入未见重复） - 拼接日期前缀（如
CONCAT(DATE_FORMAT(NOW(), '%y%m%d'), LEFT(REPLACE(UUID(), '-', ''), 16))），增强可读性和时间维度索引友好性
存储过程中批量生成并返回订单号列表的写法
不能在循环里反复调用UUID()再拼接——性能差，且无法保证原子性。推荐用临时表 + 批量生成方式：
CREATE PROCEDURE gen_order_no_batch(IN cnt INT)
BEGIN
DECLARE i INT DEFAULT 0;
DROP TEMPORARY TABLE IF EXISTS tmp_order_nos;
CREATE TEMPORARY TABLE tmp_order_nos (order_no CHAR(24) PRIMARY KEY);
WHILE i < cnt DO
INSERT IGNORE INTO tmp_order_nos
SELECT CONCAT(DATE_FORMAT(NOW(), '%y%m%d'),
LEFT(REPLACE(UUID(), '-', ''), 16));
SET i = i + 1;
END WHILE;
SELECT order_no FROM tmp_order_nos;
END;
注意：INSERT IGNORE能自动跳过重复值（靠PRIMARY KEY约束拦截），避免死循环；但实际中建议加REPEAT ... UNTIL ROW_COUNT() = cnt逻辑兜底，防止极端碰撞后数量不足。
为什么不用UUID_SHORT()或自增ID+时间戳
UUID_SHORT()依赖服务器启动时间+服务器ID+计数器，在集群或容器重启频繁的环境里容易重复；而单纯用UNIX_TIMESTAMP()*1000000 + LAST_INSERT_ID()又依赖插入顺序，在批量多行INSERT时不可控。真正稳的方案，是把“唯一性保障”交给数据库约束（唯一索引+IGNORE），把“格式控制”交给字符串拼接逻辑——而不是指望某个函数天然完美。
最易被忽略的一点：生成后的订单号如果要落库到正式表，必须在同一个事务里完成校验与插入，否则中间被其他进程抢注会导致业务错乱。别只顾着生成，忘了锁和事务边界。
