先说个核心判断：用触发器自动生成业务流水号，理论上当然可以，但前提是你得搞清楚不同数据库之间的语法差异。Oracle和PostgreSQL各有各的玩法，而MySQL压根没有原生序列，只能另辟蹊径。很多人写起来发现处处是坑，其实大部分问题都出在语义特性没吃透。

## 触发器里能不能直接用NEXTVAL生成流水号？ 能，但语法差异必须留意。Oracle和PostgreSQL都支持序列（SEQUENCE），调用方式不一样。MySQL没有原生序列，只能靠`LAST_INSERT_ID()`或者自定义函数来模拟。 关键在于，很多人会在`BEFORE INSERT`触发器里直接写`SELECT seq_name.NEXTVAL INTO :new.bill_no FROM dual`，却忘了加`FOR EACH ROW`。少了这行，触发器默认只执行一次，结果所有插入行拿到的流水号是同一个——这不是你想要的。 具体来看： - **Oracle**：必须写成`SELECT seq_bill.NEXTVAL INTO :new.bill_no FROM dual`，同时触发器声明要带上`FOR EACH ROW`。 - **PostgreSQL**：用赋值语句`NEW.bill_no := nextval('seq_bill');`，这里不能用`SELECT ... INTO`。 - **MySQL**：没有`NEXTVAL`，可以模拟成`NEW.bill_no := CONCAT('BILL', LPAD(LAST_INSERT_ID(), 6, '0'))`，但前提是自增主键已正确配置，否则可能拿到非预期结果。 ## 流水号要带日期前缀，怎么拼接才安全？ 假设你要生成“BILL202405200001”这种格式，拼接本身并不难，难的是保证时序安全。多个并发插入可能拿到相同日期部分，再叠加自增序号，重复风险相当高。 别在触发器里直接用`DATE_FORMAT(NOW(), '%Y%m%d')`拼上去。这个时间戳是语句开始时刻，不是事务提交时刻，而且不保证唯一性。在高并发场景下，这是一个常见的隐患。 各数据库的推荐做法： - **Oracle**：用`TO_CHAR(SYSDATE, 'YYYYMMDD') || LPAD(seq_bill.NEXTVAL, 6, '0')`，依赖序列的原子性保障后半段唯一。 - **PostgreSQL**：用`to_char(CURRENT_DATE, 'YYYYMMDD') || lpad(nextval('seq_bill')::text, 6, '0')`，逻辑类似。 - **MySQL**：尽量避免用`NOW()`拼接。更稳妥的做法是：在触发器中先查当前最大号，解析日期，判断是否需要重置序号——但这个方案会引入锁竞争。实际项目中，干脆把日期部分交给应用层生成，或者用带时间戳的UUID做前缀。 ## 触发器报错 ORA-04091：table is mutating，怎么解决？ 这是Oracle里最典型的陷阱。在`BEFORE/AFTER ROW`触发器中，如果你试图查询或修改正在被触发的同一张表，就会遇到这个“mutating table”错误。比如你想根据当前部门人数动态生成流水号前缀，然后在触发器里写`SELECT COUNT(*) FROM orders WHERE dept_id = :new.dept_id`——这行不通。 解决思路有三条： - **解法一**：改用`AFTER STATEMENT` + 临时表或包变量暂存数据，再异步更新。 - **解法二**：把业务逻辑提到应用层，触发器只做纯序列号填充，不做任何查询。 - **解法三**：用复合触发器（Oracle 11g+），在`BEFORE STATEMENT`阶段初始化，在`AFTER EACH ROW`阶段填充，最后在`AFTER STATEMENT`统一提交。 ## MySQL的触发器没法调用存储函数生成流水号？ 可以调用，但限制非常多。最关键的两条：不能在触发器里调用含`SELECT`或修改数据的存储函数（会报ERROR 1422），也不能调用`UUID()`这类非确定性函数。 最常踩的坑是：写了一个`SET NEW.bill_no = get_next_bill_no()`，而这个函数内部用了`INSERT INTO tmp_seq VALUES ()`——这直接违反MySQL触发器“无副作用”的要求。 可行的替代做法： - 用`INSERT ... SELECT`插入时，通过变量或应用层生成号，再传入。 - 改用生成列（Generated Column） + 自增ID组合，例如：`bill_no VARCHAR(20) AS (CONCAT('BILL', DATE_FORMAT(create_time, '%Y%m%d'), LPAD(id, 6, '0'))) STORED`。 - 如果业务确实需要强顺序流水号，建议放弃MySQL触发器，改用应用层的分布式ID生成器（比如Snowflake）。 流水号看起来很简单的字符串拼接，背后却牵涉到序列原子性、并发控制、跨库兼容性和错误恢复路径。越想“全自动”，越容易在高并发或主从切换时出问题。把底层机制理清楚再动手，才是靠谱的工程态度。