Oracle触发器自动递增version_number字段必须使用BEFORE UPDATE行级触发器，通过:new.version_number := NVL(:old.version_number, 0) + 1实现，严禁在AFTER触发器中赋值，且需显式处理NULL初始值以避免结果为NULL。
Oracle 触发器怎么自动递增 version_number 字段
必须用 BEFORE UPDATE 行级触发器，且只能操作 NEW 值；AFTER 触发器里改 :new.version_number 无效，会报错或被忽略。
常见错误是写成 AFTER UPDATE 然后试图赋值，结果字段没变、版本号卡住不动。正确写法：
CREATE OR REPLACE TRIGGER trg_bu_emp_version BEFORE UPDATE ON employees FOR EACH ROW BEGIN :new.version_number := NVL(:old.version_number, 0) + 1; END;
- 一定要用
NVL或COALESCE处理NULL初始值，否则第一次更新就变成NULL + 1 → NULL - 不要在触发器里查表或调用函数（如
SELECT COUNT(*)），会引发 mutating table 错误 - 如果表有多个触发器，注意执行顺序：Oracle 按创建时间先后执行，建议命名带序号（如
trg_bu_emp_v1）便于排查
INSERT 时 version_number 怎么初始化才不冲突
不能依赖应用层传入默认值，也不能全靠触发器在 BEFORE INSERT 中硬写死 1——万一某条记录是通过 INSERT ... SELECT 批量导入的，可能已有非空 version_number，直接覆盖会丢版本信息。
稳妥做法是只补空值：
CREATE OR REPLACE TRIGGER trg_bi_emp_version
BEFORE INSERT ON employees
FOR EACH ROW
BEGIN
IF :new.version_number IS NULL THEN
:new.version_number := 1;
END IF;
END;
- 显式判断
IS NULL，而不是用NVL(:new.version_number, 1)，避免把用户有意传入的0或负数也改成1 - 如果业务允许从
0起始（比如做乐观锁比对），那就按需调整判断逻辑，但必须和应用层约定一致 -
IDENTITY列或默认值约束（DEFAULT 1）可共存，但触发器优先级更高，会覆盖默认值——这点容易被忽略
如何避免 version_number 被绕过更新
应用层直连 Oracle 时，只要 SQL 语句显式给 version_number 赋值，触发器就完全不起作用。比如：
UPDATE employees SET name = 'Alice', version_number = 999 WHERE id = 123;
这条语句会让触发器里的 :new.version_number 直接等于 999，跳过自增逻辑。
- 最严方式：把
version_number列设为GENERATED ALWAYS AS (…)虚拟列（Oracle 12c+），但这样就不能索引、也不能用于乐观锁条件 - 更实用的方式：在应用层统一使用 ORM 的乐观锁注解（如 MyBatis 的
@Version），并禁止手写含version_number的 UPDATE 语句 - DBA 层面可用细粒度审计（
AUDIT UPDATE ON employees BY ACCESS）抓出异常赋值行为，但无法阻止
ORA_ROWSCN 能替代 version_number 吗
不能直接替代，但可作为辅助校验。ORA_ROWSCN 是块级 SCN，同一数据块内多行更新会共享相同 SCN，精度不够；且默认不开启行级跟踪（需建表时加 ROWDEPENDENCIES）。
启用后查询才有效：
CREATE TABLE employees (id NUMBER, name VARCHAR2(50)) ROWDEPENDENCIES; SELECT id, name, ORA_ROWSCN FROM employees WHERE id = 123;
- 未加
ROWDEPENDENCIES时，ORA_ROWSCN只反映数据块最后修改时间，不是行级变更戳 - 即使启用了，SCN 也不支持人工递增、无法用于乐观锁的“预期版本比对”，仅适合做粗略变更检测
- 真正需要可控版本号的场景（如 REST API 并发更新防护），还是得靠
version_number+ 触发器组合
触发器本身不维护事务边界，version_number 更新失败会导致整个 UPDATE 失败，这点必须纳入应用重试逻辑设计；另外，高并发下频繁更新同一行可能因 SCN 争用产生短暂等待，不是纯内存操作。
