mysql触发器无法安全混合自增id与日期函数生成流水号，因before insert时new.id不可用且now()多次调用结果可能不一致；推荐方案是用独立计数表+for update锁或insert...on duplicate key update配合last_insert_id()实现原子递增，并按业务类型动态拼接前缀。
MySQL 触发器本身不支持在生成流水号时“安全地混合使用自增ID与日期函数”，因为两者行为冲突：自增ID是事务提交后才确定的，而触发器在 BEFORE INSERT 阶段无法读取它；DATE_FORMAT(NOW(), '%Y%m%d') 在同一语句中多次调用可能返回不同值（尤其跨秒时），导致拼接错乱。真正能落地的方案，是放弃“依赖 order_id 自增 + 日期格式化”这种看似简洁实则不可靠的组合。
为什么不能直接用 NEW.id 和 DATE_FORMAT(NOW(), '%Y%m%d') 拼流水号
这是最常被复制粘贴却最容易出问题的写法。典型错误示例如下：
SET NEW.order_sn = CONCAT('ORD', DATE_FORMAT(NOW(), '%Y%m%d'), LPAD(NEW.id, 4, '0'));
问题不止一个：
-
NEW.id在 BEFORE INSERT 触发器里始终为0或NULL（除非你显式赋值，但此时已绕过自增机制） -
DATE_FORMAT(NOW(), '%Y%m%d')若在触发器里被调用两次（比如一次存日志、一次拼号），可能因毫秒级时间跳变产生两个不同日期字符串 - 若业务要求「每日重置」，而你用全局自增ID取模或截取，会很快溢出或撞号
用独立计数表 + FOR UPDATE 锁保障原子性
这是生产环境唯一推荐的 MySQL 方案。核心是把「日期维度」和「序号递增」拆开，用一张轻量表控制每日计数，并通过行锁避免并发冲突。
建表语句：
CREATE TABLE seq_counter ( seq_date DATE PRIMARY KEY, seq_value INT NOT NULL DEFAULT 0 );
触发器逻辑关键点：
- 先用
INSERT ... ON DUPLICATE KEY UPDATE尝试插入当天记录；失败说明已存在，就走更新分支 - 更新时必须用
UPDATE ... SET seq_value = LAST_INSERT_ID(seq_value + 1)，再通过SELECT LAST_INSERT_ID()获取新值——这是 MySQL 唯一能保证原子递增且可回滚的方式 - 不要用
SELECT MAX() + 1查再插，高并发下必然重复
示例片段（简化版）：
INSERT INTO seq_counter (seq_date, seq_value) VALUES (CURDATE(), 1) ON DUPLICATE KEY UPDATE seq_value = LAST_INSERT_ID(seq_value + 1); SELECT LAST_INSERT_ID() INTO @next_no;
按业务类型动态拼前缀，别硬编码 'ORD'
实际系统往往要支持销售单（SO）、采购单（PO）、入库单（IN）等多类单据。触发器里必须校验并分支处理：
- 先检查
NEW.business_type是否在白名单内（如'SO','PO','IN'），否则直接报错或设默认值 - 不同前缀对应不同计数行：用
seq_date+business_type联合主键，或加字段seq_type VARCHAR(4) - 补零位数建议统一为 6 位（
LPAD(@next_no, 6, '0')），避免后期排序错乱或前端展示截断
错误示范（易被忽略）：
SET NEW.bill_no = CONCAT(NEW.business_type, '-', DATE_FORMAT(NOW(), '%Y%m%d'), LPAD(@next_no, 4, '0'));
这里没判断 NEW.business_type 是否为空或非法，上线后只要某条数据漏传该字段，就会生成类似 '-202605070001' 的脏号。
真正复杂的逻辑应该交给存储过程，触发器只做调用
如果你的流水号规则涉及「节假日跳过」「按客户等级分段编号」「前缀含区域代码需查字典表」，就别在触发器里写 IF-ELSE 嵌套。这类逻辑一旦写进触发器：
- 调试极其困难（改一行要删触发器、重装、清缓存）
- 容易触发 ERROR 1442（不能修改正在变更的表）
- 性能骤降：一次 INSERT 可能变成几十次子查询
正确做法是封装成存储过程：
CREATE PROCEDURE gen_bill_no( IN p_type VARCHAR(4), IN p_region_code CHAR(2), OUT p_bill_no VARCHAR(20) ) BEGIN -- 查字典、判节假日、取序列、拼接... SET p_bill_no = CONCAT(...); END;
触发器里只留一句：CALL gen_bill_no(NEW.business_type, NEW.region_code, @sn); SET NEW.bill_no = @sn;
复杂点永远在「如何让计数表不成为单点瓶颈」和「怎么让存储过程里的查字典不拖慢主事务」——这两处才是真功夫所在，不是拼函数就能解决的。
