能，但需注意数据库差异：oracle用select…into+for each row；postgresql用new.col:=nextval()；mysql无原生序列，需模拟且避免非确定性函数。
触发器里不能直接用 NEXTVAL 生成流水号？
能，但必须注意 Oracle 和 PostgreSQL 的序列语法差异。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();，而 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）
流水号看似只是字符串拼接，实际牵扯序列原子性、并发控制、跨库兼容性和错误恢复路径——越想“全自动”，越容易在高并发或主从切换时掉链子。
