推荐用 REPLACE INTO + 唯一索引生成订单号，或 UUID_SHORT()、Snowflake；必须为 order_no 加 UNIQUE 索引并捕获重复错误重试。
_no 加 UNIQUE 索引并捕获重复错误重试。用 AUTO_INCREMENT + 业务前缀拼接不安全
很多人直接在应用层读取最大订单号、加1、拼前缀（如 "ORD2025052000001"），这在并发下必然重复。MySQL 的 SELECT MAX(id) 和 INSERT 不是原子操作，两个事务同时执行会拿到相同最大值。
即使加 SELECT ... FOR UPDATE，也只对已有行加锁，对“还没插入的下一行”无约束，且高并发时锁冲突严重、性能差。
- 不要依赖应用层自增逻辑生成唯一订单号
- 避免在事务中先查后插，尤其跨事务边界
- 若坚持用表做号段，必须用
INSERT ... SELECT ... ON DUPLICATE KEY UPDATE或REPLACE INTO配合唯一索引兜底
推荐方案：用 REPLACE INTO + 唯一索引控制单次生成
核心思路是把“生成动作”变成一条带唯一约束的写入语句，让 MySQL 自己解决冲突。建一张轻量号段表：
CREATE TABLE order_seq ( date_part CHAR(8) NOT NULL, seq INT UNSIGNED NOT NULL DEFAULT 1, PRIMARY KEY (date_part), UNIQUE KEY uk_date (date_part) );
每次生成订单号时执行：
REPLACE INTO order_seq (date_part, seq)
VALUES ('20250520', 1)
ON DUPLICATE KEY UPDATE seq = seq + 1;再用 SELECT seq FROM order_seq WHERE date_part = '20250520' 读出当前值（需在同一事务中，或用 SELECT ... FOR UPDATE）。这样能保证每日序号严格递增且不重复。
-
REPLACE INTO是DELETE + INSERT，有坑：若表有外键或触发器要小心 - 更稳妥可用
INSERT ... ON DUPLICATE KEY UPDATE，语义更清晰 - 注意
seq字段要用INT UNSIGNED防溢出，日单量超千万建议用BIGINT
终极方案：用 UUID_SHORT() 或 SNOWFLAKE 类 ID 生成器
如果订单号不要求严格时间+顺序可读，直接用 MySQL 内置的 UUID_SHORT() 最省事——它基于时间戳+服务器ID+计数器，全局唯一、无锁、高性能：
SELECT UUID_SHORT(); -- 返回类似 932715125615321088
你可将其转为固定长度字符串（如 LPAD(HEX(UUID_SHORT()), 16, '0')），或截取后 12 位拼前缀。缺点是不可排序、略长。
-
UUID_SHORT()在同一毫秒内最多生成 16M 个，够大多数业务 - 若需完全可控的格式（如
ORD20250520123456789），建议在应用层用 Snowflake 实现，但必须确保机器 ID 和时钟同步可靠 - 别用
UUID()（带横线、无序、存储和索引效率低）
唯一性校验不能只靠应用层，必须加 UNIQUE 索引
无论用哪种生成方式，最终插入订单主表时，order_no 字段必须有 UNIQUE 索引。这是最后一道防线：
ALTER TABLE `orders` ADD UNIQUE KEY `uk_order_no` (`order_no`);
当并发写入撞上重复值，MySQL 会报错 ERROR 1062 (23000): Duplicate entry 'ORD2025052000001' for key 'uk_order_no'。此时应用应捕获该错误，重试生成逻辑（而非忽略或抛异常）。
- 索引一定要建在真正用于查询和去重的字段上，别漏掉
- 不要依赖“概率极低就不会撞”——线上高并发下，1% 的失败率就是服务雪崩起点
- 重试次数建议限制（如 3 次），避免死循环；重试间隔可加小随机抖动
实际中最容易被忽略的是：把生成逻辑和唯一性保障割裂开。生成函数返回了号，不代表它真能入库——UNIQUE 约束必须存在，且应用必须处理 ER_DUP_ENTRY 错误。
