不能靠 NEW.id 拼接日期生成高并发唯一流水号，因NEW.id在BEFORE INSERT中未生成且NOW()存在毫秒跳变风险；必须用独立计数表+ON DUPLICATE KEY UPDATE配合LAST_INSERT_ID()实现原子递增。
不能靠 NEW.id 拼接日期生成高并发唯一流水号，MySQL 触发器机制决定了这种写法在并发或跨秒场景下必然重复；真正能落地的方案是用独立计数表 + INSERT ... ON DUPLICATE KEY UPDATE 配合 LAST_INSERT_ID() 实现原子递增。
为什么 NEW.id 和 NOW() 组合在触发器里不可靠
很多人直接在 BEFORE INSERT 触发器里写：SET NEW.sn = CONCAT('ORD', DATE_FORMAT(NOW(), '%Y%m%d'), LPAD(NEW.id, 4, '0'))，但这是错的：
-
NEW.id在BEFORE INSERT阶段尚未生成，值为0或NULL（取决于表定义），拼出来全是类似ORD202611040000的固定值 -
NOW()多次调用可能因毫秒跳变返回不同日期字符串，比如触发器里一次用于日志、一次用于拼号，结果变成ORD20261104...和ORD20261105... - 即使改用
AFTER INSERT，也不能再修改本行字段，MySQL 会报错Can't update table 'xxx' in stored function/trigger
必须用独立计数表 + ON DUPLICATE KEY UPDATE
这是 MySQL 5.7/8.0 在触发器中实现原子递增的唯一可行路径。核心是把「日期维度」和「序号递增」解耦，靠主键冲突触发更新，再用 LAST_INSERT_ID() 捕获新值：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 建表语句：
CREATE TABLE seq_counter (date_key CHAR(8) PRIMARY KEY, seq INT DEFAULT 0) - 触发器内关键逻辑：
INSERT INTO seq_counter VALUES (DATE_FORMAT(NOW(), '%Y%m%d'), 1) ON DUPLICATE KEY UPDATE seq = LAST_INSERT_ID(seq + 1) - 紧接着必须立刻执行：
SELECT LAST_INSERT_ID() INTO @next_seq——中间不能穿插任何其他 SQL，否则LAST_INSERT_ID()被覆盖 - 最后拼接：
CONCAT('ORD', DATE_FORMAT(NOW(), '%Y%m%d'), LPAD(@next_seq, 4, '0'))
业务前缀动态拼接与白名单校验
如果订单类型（business_type）决定前缀（如 'SO'、'PO'），不能硬编码进触发器逻辑：
- 先检查字段是否为空或非法：
IF NEW.business_type NOT IN ('SO', 'PO', 'INV') THEN SET NEW.bill_no = 'ERR-INVALID-TYPE'; END IF; - 计数表需支持多业务线：把
business_type和date_key组合成联合主键，或用CONCAT(business_type, '-', date_key)作主键 - 避免在触发器里查大表（如
SELECT MAX() FROM orders WHERE ...），全表扫描 + LIKE 匹配极慢，且锁表范围不可控 - 时区陷阱：统一用
CURDATE()而非DATE(NOW())，并确认@@session.time_zone与业务预期一致，否则ORD20261104可能变成ORD20261103
最容易被忽略的是：触发器里任何 SQL 报错（比如计数表不存在、权限不足、LPAD 参数超长）都会让整个 INSERT 回滚，但应用层只看到“插入失败”，错误日志却藏在触发器执行链里。上线前务必用 DROP TRIGGER 临时禁用，手动跑一遍触发逻辑，验证每张表、每个函数、每个权限是否就位。
