数据表里那两列create_time和update_time几乎是每个业务系统都绕不开的东西。我见过太多项目在这上面翻车有人靠应用层在每次UPDATE前手动塞时间戳结果某个批量脚本漏写了数据就悄悄错乱有人图省事用ON UPDATE CURRENT_TIMESTAMP换到国产数据库上直接报语法错误。这次聊的是在 DM7达梦数据库里用触发器把时间戳维护这件事做扎实——不是贴一段 SQL 就完事而是把为什么这么写哪里会踩坑怎么验证它真的生效讲透。适合正在做数据库迁移、或者要给存量表补自动时间戳的同学也适合刚接触 DM7 触发器、想搞清楚:NEW和:OLD到底怎么用的人。下面这套方案我在几个模拟项目里反复跑过DDL 和 DML 都验证过可以直接抄。1. 先想清楚时间戳到底该由谁来维护动手写触发器之前有个问题必须先定下来自动时间戳的维护责任放在哪一层。这个选择直接决定了后面触发器怎么写、写几个、以及会不会和业务代码打架。很多人一上来就写 SQL写到一半发现应用层也在赋值两边互相覆盖最后时间戳乱得像一锅粥。1.1 三种维护位置的取舍逻辑常见的做法无非三种我把它们的特性摆在一起对比你对着自己的场景挑维护位置实现方式优点明显短板应用层每次写库前代码里setUpdateTime(now)逻辑集中、可控性强任何绕过该代码的入口批量脚本、手工修数、其他服务都会漏表定义列级默认值 / 自动更新属性零代码、性能好DM7 对列级自动更新支持有限跨库迁移不通用数据库触发器BEFORE INSERT/UPDATE触发器赋值与入口无关任何写入都生效有轻微性能开销逻辑藏在库里不易发现核心判断标准其实就一句话这张表会不会有多个写入入口。如果一张表只被一个服务的固定方法写应用层维护完全够用还省得排查问题时去翻数据库。但只要存在第二个入口——数据订正脚本、定时任务、别的服务直连——应用层方案就必然出现漏网之鱼。触发器最大的价值就在于它是入口无关的不管谁往表里写时间戳都会被兜住。我个人的取舍是核心业务表用触发器兜底应用层该赋值还是赋值。两层都写不冲突因为触发器在BEFORE阶段执行会用数据库时间覆盖掉应用传进来的值保证时间基准统一。这一点很关键——如果应用服务器和数据库服务器时钟有偏差统一用数据库时间能避免更新时间比创建时间还早这种诡异数据。1.2 为什么选 BEFORE 而不是 AFTERDM7 的触发器分BEFORE和AFTER两类时间戳场景必须用BEFORE原因很直接AFTER触发器执行时行已经写进表了你想改时间戳就得再发一条UPDATE等于一次写入变两次还可能触发递归。而BEFORE触发器在行落盘前执行可以直接修改:NEW伪记录里的字段值改完数据库拿到的就是最终值一次写入搞定。这里有个容易混淆的点BEFORE触发器里对:NEW.列名的赋值是真正会写进表的不是只读的副本。DM7 的:NEW在BEFORE行级触发器里可读可写这正是我们能篡改时间戳的依据。而:OLD在INSERT触发器里根本不存在没有旧行在UPDATE触发器里只读别想着去改它。1.3 一个表要写几个触发器时间戳涉及两种操作插入时要填创建时间和更新时间更新时要刷新更新时间。直觉上会想写两个触发器一个管INSERT一个管UPDATE。但 DM7 支持在一条CREATE TRIGGER里用INSERT OR UPDATE同时覆盖两种事件写一个就够了维护起来也清爽。不过要注意合并成一个触发器后触发器体里必须用INSERTING/UPDATING这类条件谓词区分当前是哪种操作否则INSERT时去访问:OLD会出问题。这个细节后面写代码时会具体展开。2. 建表阶段就把字段类型和默认值定对触发器写得再漂亮字段类型选错了照样白搭。时间戳字段的类型和精度是很多隐蔽问题的源头值得单独拎出来说。2.1 TIMESTAMP 的精度选择DM7 里存时间戳常用TIMESTAMP和DATETIME两种。DATETIME默认精度到秒部分兼容模式下可到毫秒TIMESTAMP可以显式指定小数秒位数比如TIMESTAMP(6)表示精确到微秒。如果你的业务存在同一秒内多次更新同一行的情况高频状态机、计数器类表秒级精度会导致多条更新记录时间戳完全相同做增量同步或审计时无法区分先后。我的建议是审计、同步、状态流转类表一律用TIMESTAMP(6)多占的那点存储换来的是排序和去重的确定性。纯展示用途、更新频率低的配置表秒级精度足够没必要上微秒。CREATE TABLE t_biz_order ( order_id BIGINT NOT NULL PRIMARY KEY, order_status VARCHAR(32), amount DECIMAL(18,2), create_time TIMESTAMP(6) DEFAULT CURRENT_TIMESTAMP, update_time TIMESTAMP(6) DEFAULT CURRENT_TIMESTAMP, remark VARCHAR(200) );注意这里给两列都设了DEFAULT CURRENT_TIMESTAMP。这不是多此一举——触发器是兜底默认值是第二道保险。万一哪天触发器被误删或者被禁用插入时至少还有个合理的时间不至于出现NULL导致下游空指针。这种双保险思路在数据库设计里很实用成本几乎为零。2.2 默认值会不会和触发器冲突有人担心列上设了默认值触发器又赋值会不会打架不会。执行顺序是INSERT语句没给该列值时先应用列默认值生成初始行然后BEFORE INSERT触发器执行用:NEW.create_time : SYSDATE覆盖掉默认值。最终落盘的是触发器赋的值。两者是先默认、后覆盖的关系不冲突。真正需要留意的是UPDATE场景UPDATE语句如果显式写了update_time 某值触发器照样会覆盖它。这既是优点保证时间基准统一也是坑如果业务真的需要手工指定更新时间比如数据迁移要保留原始时间触发器会把它改掉。遇到这种迁移场景正确做法是迁移期间临时禁用触发器导完再启用而不是去改触发器逻辑。2.3 给时间戳列加索引的时机update_time经常被用来做增量抽取的游标比如捞取最近 5 分钟内更新的记录。这种查询如果不加索引每次都要全表扫表一大就扛不住。但索引也不是无脑加——update_time是高频变化的列每次更新都会导致索引条目变更写放大明显。判断标准如果update_time只用于展示不加索引如果用于增量同步的过滤条件加。加的时候建议用普通 B-Tree 索引即可不需要函数索引。另外如果增量抽取是按update_time范围扫描可以考虑和主键做联合索引避免回表但这属于进阶优化先保证功能正确再谈。3. 触发器本体一条语句覆盖插入与更新现在进入正题。DM7 的触发器语法和主流数据库大体相似但伪记录引用、条件谓词的写法有自己的规矩照搬别的库的脚本大概率报错。3.1 完整可执行的触发器 DDL先给能直接跑的版本再逐段拆解CREATE OR REPLACE TRIGGER trg_biz_order_ts BEFORE INSERT OR UPDATE ON t_biz_order FOR EACH ROW BEGIN IF INSERTING THEN :NEW.create_time : SYSDATE; :NEW.update_time : SYSDATE; ELSIF UPDATING THEN :NEW.update_time : SYSDATE; END IF; END; /几个关键点逐个说CREATE OR REPLACEDM7 支持这个写法重复执行不会报已存在方便脚本化管理。如果你的环境不支持就先DROP TRIGGER IF EXISTS再建。BEFORE INSERT OR UPDATE一条语句绑定两种事件省去写两个触发器。FOR EACH ROW行级触发器必须加。不加就是语句级:NEW根本不可用。IF INSERTING THEN ... ELSIF UPDATING THEN条件谓词用来区分当前触发的是哪种 DML。这是合并触发器的核心。SYSDATEDM7 里返回当前数据库时间。也可以用CURRENT_TIMESTAMP精度更高带小数秒和TIMESTAMP(6)列更匹配。我一般用SYSDATE图省事对精度有要求的场景换成CURRENT_TIMESTAMP。注意INSERTING/UPDATING是触发器内的布尔谓词不是函数不要写成INSERTING()。写成带括号的形式在 DM7 里会报错。3.2 为什么 INSERT 分支要同时赋两列INSERT时create_time和update_time都赋当前时间逻辑上很自然新插入的行创建时间和最后更新时间就是同一时刻。但有人会问既然列上已经有DEFAULT CURRENT_TIMESTAMP了INSERT分支是不是可以省掉技术上可以省但我不建议。原因有两个一是显式赋值让触发器行为一目了然别人看代码就知道插入时时间戳由触发器管不用再去翻表定义二是如果哪天有人把列默认值删了比如为了兼容某个老系统触发器还能兜住。显式优于隐式在数据库这种改一处影响一片的地方尤其成立。另外INSERT分支里不要去碰:OLD。INSERT操作没有旧行访问:OLD.任何字段在 DM7 里会抛异常。这也是为什么必须用IF INSERTING把两种操作隔离开——不隔离的话INSERT走到访问:OLD的分支就炸了。3.3 UPDATE 分支只刷 update_time 的深意UPDATE分支只改update_time绝不动create_time。这条规则看起来天经地义但实际项目里真有人写错过——把create_time也一起刷新了结果审计时发现所有记录的创建时间都变成了最后一次修改时间历史追溯彻底失效。create_time的语义是这行数据第一次诞生的时刻一旦写入就应该永久不变。触发器里不碰它就是对这个语义的守护。如果业务上确实需要记录首次生效时间之类的字段那是另一个列的事不要和create_time混为一谈。还有个细节UPDATE触发器会对每一行被更新的记录触发。一条UPDATE ... WHERE影响 1000 行触发器就执行 1000 次每行各自赋当前时间。如果这 1000 行是在同一毫秒内处理完的它们的update_time可能完全相同——这在批量更新场景下是正常的不要指望靠update_time区分同批次内的行序那得靠主键或序列。3.4 触发器体的异常处理要不要加标准写法里我没加EXCEPTION块因为时间戳赋值这种操作几乎不可能抛异常SYSDATE不会失败:NEW赋值也不会。加了反而是噪音。但有一种情况值得考虑如果触发器里除了时间戳还要做别的逻辑比如写审计日志表那EXCEPTION就有必要了——审计写失败不应该阻断主业务写入。这时候用EXCEPTION WHEN OTHERS THEN NULL吞掉异常但要配合日志记录否则出了问题查不到。纯时间戳触发器保持精简就好。4. 验证怎么确认触发器真的在干活写完 DDL 只是开始不验证等于没写。我见过触发器语法正确但逻辑写反、或者根本没被触发的案例上线后才发现时间戳全是旧值。下面这套验证流程建议每次都走一遍。4.1 插入验证两列是否都等于当前时间INSERT INTO t_biz_order (order_id, order_status, amount) VALUES (1001, CREATED, 99.50); SELECT order_id, create_time, update_time FROM t_biz_order WHERE order_id 1001;预期结果create_time和update_time都等于插入时刻且两者相等同一语句内SYSDATE取值一致。如果create_time是NULL说明触发器没生效或者INSERT分支没走到如果两列不相等检查是不是SYSDATE被调用了两次跨了秒边界——概率极低但理论上存在对精度敏感的场景用变量先存一次时间再赋给两列更稳。4.2 更新验证create_time 必须纹丝不动-- 先记下原始 create_time SELECT create_time FROM t_biz_order WHERE order_id 1001; -- 等一两秒再更新便于观察时间变化 UPDATE t_biz_order SET order_status PAID WHERE order_id 1001; SELECT create_time, update_time FROM t_biz_order WHERE order_id 1001;预期update_time变成更新时刻create_time和更新前完全一致。如果create_time也变了说明UPDATE分支误写了:NEW.create_time回去检查触发器体。如果update_time没变可能是触发器没绑定UPDATE事件或者UPDATING谓词拼写有误。4.3 用数据字典确认触发器状态DM7 里可以查系统视图确认触发器是否存在、是否启用SELECT trigger_name, table_name, status, triggering_event FROM user_triggers WHERE table_name T_BIZ_ORDER;status为ENABLED才算生效。如果显示DISABLED用ALTER TRIGGER trg_biz_order_ts ENABLE;打开。迁移或批量导入后触发器被自动禁用是常见现象导入完记得回来查一眼。4.4 一个容易忽略的验证点批量更新单行验证通过不代表批量没问题。补一条批量更新测试UPDATE t_biz_order SET remark batch test WHERE order_status PAID;更新完抽查几行确认每行的update_time都刷新了。行级触发器对每行都执行理论上不会有遗漏但如果你不小心写成了语句级漏了FOR EACH ROW批量更新时:NEW不可用行为会完全不同——这种错误单行测试可能暴露不出来批量测试才能抓到。5. 踩过的坑这些情况会让触发器失灵触发器这东西写对了很省心写错了排查起来很折磨因为它的执行是隐式的出错信息往往指向别处。下面几个坑我都真实遇到过按踩中概率从高到低排。5.1 批量导入时触发器被禁用或绕过做数据迁移时为了提速经常会临时禁用触发器导完忘了启用结果新写入的数据时间戳全是NULL或默认值。更隐蔽的是某些导入工具会显式设置会话参数跳过触发器导入成功了但时间戳没维护。排查链路是这样的先查user_triggers的status确认是ENABLED再手工插一条测试数据看时间戳对不对如果手工插对、工具导不对那就是工具层面的问题检查导入参数里有没有禁用触发器的选项。迁移后的第一件事永远是插一条测试数据验证触发器这个习惯能省掉大量事后排查。5.2 触发器里引用了不存在的列名DM7 编译触发器时对列名的校验比较严格但有些环境允许延迟解析建触发器时不报错真正执行 DML 时才抛无效的列名。典型场景是表结构变更后列名改了触发器没跟着改。比如把update_time改名成last_modified触发器里还写着:NEW.update_time建的时候不报错一更新就炸。这类问题的排查方法是表结构变更后把所有关联触发器列出来逐个检查。DM7 可以查user_triggers的trigger_body字段看到触发器源码对着新表结构核一遍列名。5.3 递归触发导致的栈溢出如果触发器里除了赋值还做了别的 DML比如往另一张表写日志而那张表的触发器又反过来操作原表就会形成递归。DM7 有递归深度限制超了会报错。纯时间戳触发器不会递归只改:NEW不发起新 DML但如果你在触发器里加了审计逻辑就要小心。避免递归的原则触发器里尽量只操作:NEW/:OLD不发起额外的 DML。确实需要写审计的用独立的审计表且该表不再挂触发器或者用数据库自带的审计功能别自己用触发器套触发器。5.4 时区问题导致时间戳穿越SYSDATE返回的是数据库服务器所在时区的时间。如果应用服务器和数据库服务器不在同一时区或者数据库迁移跨了时区就会出现更新时间比创建时间早 8 小时这种数据。这不是触发器写错了是时间基准不统一。解决办法统一用数据库时间触发器方案天然满足应用层展示时按需转换时区绝不要在应用层生成时间再传给数据库。如果业务确实需要存 UTC 时间那就把SYSDATE换成SYS_EXTRACT_UTC(SYSTIMESTAMP)之类的 UTC 取值函数全库统一别一半 UTC 一半本地时间。5.5 大事务下的锁等待放大行级触发器在每行更新时执行本身开销很小但在超大事务一次更新几十万行里触发器执行次数等于行数累积起来会拉长事务持有锁的时间增加锁等待概率。这不是触发器独有的问题任何行级逻辑都有这个特性。应对办法大批量更新拆成小批次提交每批几千行既降低锁持有时间也避免 undo 空间暴涨。如果某次批量操作确实不需要维护时间戳比如纯数据订正临时禁用触发器、操作完再启用比硬扛着跑更明智。6. 进阶让时间戳方案更贴合真实业务基础方案跑通后可以根据业务特点做一些增强。这些不是必须的但用对了能解决不少实际问题。6.1 只在实际字段变化时才刷新 update_time默认方案下哪怕UPDATE语句把某列改成了和原来一样的值update_time也会刷新。这在空更新频繁的场景下会产生误导——时间戳显示刚更新过实际数据没变增量同步会白跑一趟。要做到值真变了才刷新得在触发器里逐列比较:OLD和:NEWCREATE OR REPLACE TRIGGER trg_biz_order_ts BEFORE INSERT OR UPDATE ON t_biz_order FOR EACH ROW BEGIN IF INSERTING THEN :NEW.create_time : SYSDATE; :NEW.update_time : SYSDATE; ELSIF UPDATING THEN IF :OLD.order_status :NEW.order_status OR :OLD.amount :NEW.amount OR :OLD.remark :NEW.remark THEN :NEW.update_time : SYSDATE; ELSE :NEW.update_time : :OLD.update_time; END IF; END IF; END; /注意ELSE分支如果没有任何业务列变化必须把update_time显式还原成:OLD.update_time否则:NEW.update_time会保留UPDATE语句里传的值可能是应用层塞的当前时间等于没拦住。这个还原动作是很多人漏掉的一步。代价是触发器体变长每列都要比较表宽的时候维护成本高。我的经验是列少10 列以内且空更新频繁的表值得这么做列多或者更新本来就都有意义的表用基础方案就行别为了省几次同步把触发器搞得又长又脆。6.2 用序列或自增列配合时间戳做增量抽取update_time做增量游标有个天然缺陷同一时刻更新的多行游标无法精确定位到上次处理到哪一行容易漏数据或重复处理。解决办法是引入一个单调递增的版本列和时间戳配合使用。-- 加一个版本列 ALTER TABLE t_biz_order ADD version_no BIGINT DEFAULT 0; -- 触发器里每次更新自增 -- 在 UPDATING 分支追加 -- :NEW.version_no : :OLD.version_no 1;增量抽取时用WHERE (update_time :last_time) OR (update_time :last_time AND version_no :last_version)这样的复合条件能精确断点续传。这套组合在数据同步场景里很常见时间戳负责粗筛版本号负责精确定位。6.3 触发器命名规范与集中管理一个库里有几十上百个触发器时命名混乱会让排查变成噩梦。我的习惯是统一前缀加表名trg_表名_用途比如trg_biz_order_ts表示订单表的时间戳触发器。这样按前缀一搜就能列出所有触发器迁移或重构时不会漏。另外把所有触发器的 DDL 纳入版本管理和建表脚本放一起别只在数据库里改。触发器逻辑藏在库里光看应用代码根本发现不了只有脚本化才能保证环境之间一致。每次表结构变更同步更新触发器脚本这是纪律问题不是技术问题。6.4 什么时候该放弃触发器改用其他方案触发器不是银弹。如果出现以下情况值得重新考虑方案触发器逻辑复杂到超过 50 行、触发器里需要调用外部逻辑、团队对数据库层逻辑普遍不熟悉导致维护困难。这些场景下把时间戳维护收敛到统一的数据访问层比如所有写操作走同一个 DAO 基类配合数据库的列默认值兜底可能比触发器更好维护。判断的核心还是那句话写入入口是否可控。入口收敛且团队规范到位应用层方案完全可行入口分散或者有大量手工操作触发器就是最省心的兜底。没有绝对的对错只有匹不匹配。7. 收尾前再叮嘱几句实操细节写到这里方案和坑都覆盖得差不多了。最后补几个零碎但很实用的点都是实际动手时容易卡住的地方。第一DM7 的触发器脚本结尾那个/别漏。在命令行工具里执行时/是语句结束符漏了会导致语句一直等待输入看起来像卡死。用图形化工具时通常不需要但脚本化执行时加上更保险。第二测试环境验证过的触发器上生产前再跑一遍验证脚本。不同环境的表结构可能有细微差异比如某列在生产是NOT NULL测试环境不是触发器行为可能不同。把第 4 节的验证 SQL 存成一个脚本每次部署后执行形成习惯。第三监控时间戳的异常值。定期跑一条SELECT COUNT(*) FROM 表 WHERE update_time create_time正常应该恒为 0。一旦出现非零说明有时区问题或者触发器被绕过早发现早处理。这条检查成本极低建议纳入日常巡检。第四触发器禁用期间产生的数据要补。如果因为迁移或批量操作临时禁用了触发器操作完除了重新启用还要检查这段时间写入的数据时间戳是否正确必要时用UPDATE补一遍补的时候记得触发器已经启用别又触发一轮刷新可以临时再禁一次或者用条件排除。我个人在实际操作中的体会是时间戳这种看起来简单的需求恰恰最容易在细节上翻车。触发器方案的价值不在于它多高级而在于它把维护责任从每个写入方自觉变成了数据库强制这个转变能消灭掉一大类隐蔽的数据问题。把上面这套 DDL、验证流程和踩坑清单走一遍基本就能在自己的库里稳稳落地了。