oracle触发器中必须用:new.col := seq.nextval赋值语法，禁用select ... into；需注意大小写、fm格式修饰、lpad补零及cache跳号风险。
Oracle触发器里调用序列必须用赋值语法，不能写SELECT INTO
直接在 BEFORE INSERT FOR EACH ROW 触发器里写 SELECT seq_name.NEXTVAL INTO :NEW.no FROM DUAL，99%会报错——不是语法错，而是执行上下文问题。Oracle 在某些版本（尤其是 12c+ 多租户）中，SELECT ... FROM DUAL 在触发器内会被视为非确定性操作，可能触发 ORA-04091: table is mutating 或 ORA-00904: invalid identifier。
正确写法只有一条：:NEW.no := seq_name.NEXTVAL。这是 PL/SQL 赋值语句，不走 SQL 引擎解析，绕过所有上下文限制。
- 必须用
:=，不是= -
:NEW前的冒号不能漏，否则变成普通变量赋值，不会写入新行 - 序列名大小写要和
CREATE SEQUENCE时完全一致（默认大写）
按日期分段编号（如20260605-0001）得拼字符串，但TO_CHAR要防NLS环境差异
业务要求“每天重置”，本质是把日期部分作为前缀、序号部分独立计数。常见错误是直接写 TO_CHAR(SYSDATE, 'YYYYMMDD')，结果在不同数据库实例或会话里因 NLS_DATE_FORMAT 设置不同，返回格式错乱（比如变成 2026-06-05），导致前缀长度不一致、排序失效甚至唯一约束冲突。
安全写法是显式指定格式模型，并加 'fm' 修饰符去除前导空格：
:NEW.no := TO_CHAR(SYSDATE, 'fmyyyyMMdd') || '-' || LPAD(seq_name.NEXTVAL, 4, '0');
-
fm防止 Oracle 在某些格式下自动补空格（如YEAR格式） -
LPAD(..., 4, '0')确保位数统一，避免'SO-1'和'SO-10'字符串排序错位 - 别在触发器里查表算当天最大号——高并发下必然重复，序列才是唯一可靠来源
并发下跳号是正常行为，不是 bug，但要提前对齐业务预期
只要调用了 seq_name.NEXTVAL，号就占了。事务回滚、触发器异常退出、连接中断……都会导致号码“消失”。这不是缺陷，是序列对象的设计哲学：用空间换性能，靠原子递增保证唯一性，而非连续性。
如果你的业务合同或审计要求“绝对不跳号”，那序列 + 触发器方案本身就不适用——得换计数表 + 行锁（性能差十倍以上），或者改用应用层预生成池。
- 缓存值（
CACHE 20）越大，跳号越明显，但插入性能越高 - 生产环境建议
CACHE 10~50，兼顾性能与跳号心理接受度 - 千万别为“不跳号”在触发器里加
SELECT MAX(...) + 1—— 并发一上来就是死锁或重复
别在AFTER INSERT里UPDATE同一张表，mutating table错误无法绕过
流水号必须在插入前定下来。如果误用 AFTER INSERT，再试图 UPDATE orders SET bill_no = ... WHERE id = :NEW.id，Oracle 会立刻抛 ORA-04091。这不是权限或语法问题，是 Oracle 内核级保护：禁止在触发器中读/写正在被修改的表。
所有需要写入主键或唯一字段的逻辑，只能放在 BEFORE INSERT FOR EACH ROW 中，且必须通过 :NEW.xxx := ... 直接赋值。
-
AFTER INSERT只能做日志记录、通知、更新其他无关表 - 想实现“插入后补全其他字段”？把那些字段也挪到
BEFORE里一起赋值 - 触发器里调用函数？确保该函数不含任何对本表的 DML 或 SELECT
MINVALUE 和 MAXVALUE 如果设得太紧（比如 MAXVALUE 9999），一旦当天流水超限，下次 NEXTVAL 就直接报错，而不是静默归零——业务会卡死，但错误日志里只显示序列耗尽，很难联想到是配置问题。
