用 AUTO_INCREMENT
+ 业务前缀拼接不安全
很多人直接在应用层读取最大订单号、加1、拼前缀（如
"ORD2024052000001"），这在并发下必然重复。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 ('20240520', 1)
ON DUPLICATE KEY UPDATE seq = seq + 1;再用
SELECT seq FROM order_seq WHERE date_part = '20240520'读出当前值（需在同一事务中，或用
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 个，够大多数业务 若需完全可控的格式（如
ORD20240520123456789），建议在应用层用 Snowflake 实现，但必须确保机器 ID 和时钟同步可靠 别用
UUID()（带横线、无序、存储和索引效率低）
唯一性校验不能只靠应用层，必须加 UNIQUE
索引
无论用哪种生成方式，最终插入订单主表时，
order_no字段必须有
UNIQUE索引。这是最后一道防线：
ALTER TABLE `orders` ADD UNIQUE KEY `uk_order_no` (`order_no`);
当并发写入撞上重复值，MySQL 会报错
ERROR 1062 (23000): Duplicate entry 'ORD2024052000001' for key 'uk_order_no'。此时应用应捕获该错误，重试生成逻辑（而非忽略或抛异常）。 索引一定要建在真正用于查询和去重的字段上，别漏掉 不要依赖“概率极低就不会撞”——线上高并发下，1% 的失败率就是服务雪崩起点 重试次数建议限制（如 3 次），避免死循环；重试间隔可加小随机抖动
实际中最容易被忽略的是：把生成逻辑和唯一性保障割裂开。生成函数返回了号，不代表它真能入库——
UNIQUE约束必须存在，且应用必须处理
ER_DUP_ENTRY错误。
