这两天有个做订单系统的同学跑过来跟我抱怨：业务方总说订单状态变了，却说不清是谁改的。代码翻了一遍发现，更新状态的入口少说七八个，有的改了字段忘了写日志，有的记了日志忘了写操作人。这类问题我在项目里见过不止一次，最后的解决思路都很一致：在 MySQL 里把关键逻辑下沉到数据库层，用触发器把每一次变更自动落进一张审计表。
这篇继续 MySQL 学习系列，把触发器一次讲透。我不打算按官方手册从头念到尾，而是按实际项目里最舒服的顺序来：先聊清楚什么场景才值得用触发器，再手写一个能直接跑的例子，然后重点把 NEW、OLD、递归触发、批量操作、字符集这些坑讲明白。适合刚学完 SQL 基础的同学，也适合那些正在被审计需求、统计需求反复折腾的人参考。
1. 先把“触发器能不能用”这件事想清楚
1.1 触发器是数据库里的“自动开关”
触发器说白了就是一段挂在表上的 SQL 代码：当某类 DML 事件发生的时候，由数据库自动执行。你可以把它理解成一个开关——有人按了 INSERT、UPDATE、DELETE 的按钮，开关就会自动接通，后面挂着的灯泡跟着亮，不需要应用程序显式调用。
这个“自动”两个字，是触发器最核心的价值，也是最容易出问题的根源。价值在于：你不需要约束所有应用入口都写同一段日志逻辑，数据库层面就帮你兜底了。容易出问题在于：如果业务逻辑本身复杂，你却把它塞进触发器，那这段逻辑就对所有人隐藏了。以后接手项目的人看应用代码，完全不知道这一步还触发了其他表的写入，排查问题的时候就像进了黑盒。
所以我通常会把触发器当成一个“默认不推荐，特殊场景才用”的工具。它适合解决的是那种高频、固定、简单的数据维护动作，比如记录变更日志、回填时间字段、维护冗余统计、补充默认值。它不适合解决的是业务流程，尤其是需要调用外部接口、依赖其他服务的场景。
1.2 适合与不适合的场景对照
我整理了一张自己经常用来判断的对照表，你在做技术选型的时候可以直接参考：
| 适合用触发器的场景 | 典型示例 | 不适合用触发器的场景 | 典型示例 |
|---|---|---|---|
| 审计日志 | 订单状态变更记录、敏感字段更新记录 | 调用外部接口 | 发送短信、Webhook 通知 |
| 自动回填字段 | 统一更新时间、创建人 | 复杂业务状态机 | 订单状态流转中的规则判断 |
| 简单一致性维护 | 统计表增量更新、库存强一致 | 跨服务数据同步 | 主库写入后同步到缓存服务 |
| 数据默认值生成 | 自动补业务编号 | 大批量数据加载 | 初始化数据、ETL 导入数万行 |
为什么不适合？核心原因是事务边界。一个触发器里如果写了外部调用，那么在数据库事务还没提交的时候，外部系统就已经收到消息了。这个过程在事务里是失控的，如果后面某个环节失败回滚，外部系统的调用却已经发生，两边数据就彻底对不上了。复杂业务规则也一样，写在应用层，至少代码评审能看到、能在测试环境模拟；写在触发器里，往往只有出问题的时候才有人想起来去查。
当你遇到一个需求，第一反应不是“能不能用触发器”，而是“这个动作是不是必须跟数据变更严格保持同一事务”。如果答案是“必须”，比如审计日志必须跟主表数据同生共死，那触发器就是个好选择。如果答案是“不用，晚一点同步也没关系”，那还是尽快绕道，别把麻烦塞进库里。
2. 手写第一个触发器：订单变更审计表的完整落地
2.1 先定好两张表
讲概念不如直接写代码。我做了一个模拟的订单系统来演示，场景是：每次订单表里的状态或金额发生变化，都要把变更前后记录到日志表。
先准备主表：
CREATE TABLE `orders` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `order_no` VARCHAR(32) NOT NULL COMMENT '订单号', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1已支付 2已发货 3已完成 4已取消', `total_amount` DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '订单总额', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表';再加一张审计表：
CREATE TABLE `order_change_log` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `order_id` INT UNSIGNED NOT NULL COMMENT '订单ID', `old_status` TINYINT DEFAULT NULL COMMENT '变更前状态', `new_status` TINYINT DEFAULT NULL COMMENT '变更后状态', `old_amount` DECIMAL(10,2) DEFAULT NULL COMMENT '变更前金额', `new_amount` DECIMAL(10,2) DEFAULT NULL COMMENT '变更后金额', `change_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `changed_by` VARCHAR(50) DEFAULT NULL COMMENT '操作人账号', PRIMARY KEY (`id`), KEY `idx_order_id` (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单变更审计表';这里有个小细节：审计表里我没有设置外键，而是只建一个普通索引。因为订单主表可能会删历史数据，如果外键挂在审计表上，删除主表数据会非常痛苦，审计历史也会被牵连。
2.2 创建触发器的完整 SQL 和 DELIMITER 的由来
第一个触发器就挂在 orders 表的 UPDATE 事件上，把变更前后写进日志表：
DELIMITER $$ CREATE TRIGGER trg_orders_audit AFTER UPDATE ON orders FOR EACH ROW BEGIN INSERT INTO order_change_log ( order_id, old_status, new_status, old_amount, new_amount, changed_by ) VALUES ( NEW.id, OLD.status, NEW.status, OLD.total_amount, NEW.total_amount, @operator ); END$$ DELIMITER ;很多初学者第一次看到DELIMITER $$都会愣一下。这行不是 SQL 语法，而是给 mysql 命令行客户端用的分隔符指令。因为默认分隔符是分号，而触发器主体里包含多条以分号结尾的语句，如果不临时换掉分隔符，客户端会在第一个分号处误以为语句已经结束，根本没法把整个定义提交给服务器。
这里我还用了一个会话变量@operator。它的含义是：应用程序在发起更新之前先执行一句SET @operator = 'zhangsan';，触发器写日志的时候就能读取这个变量作为操作人。当然，这个方式并不完美，后面我会讲它的边界问题，但用来快速落地审计需求是够用的。
2.3 验证：一条 UPDATE 之后看结果
先插入一条订单，再执行更新：
INSERT INTO orders(order_no, status, total_amount) VALUES ('A20250318001', 0, 599.00); SET @operator = 'zhangsan'; UPDATE orders SET status = 1, total_amount = 599.00 WHERE order_no = 'A20250318001';然后检查审计表：
SELECT order_id, old_status, new_status, old_amount, new_amount, changed_by FROM order_change_log;你会看到这条日志长得非常工整：
| order_id | old_status | new_status | old_amount | new_amount | changed_by |
|---|---|---|---|---|---|
| 1 | 0 | 1 | 599.00 | 599.00 | zhangsan |
这就是触发器最直观的用法。不用应用层写任何埋点，只要有人直接连数据库改了这条记录，审计一样肉眼可见。我在这类项目里遇到过不少“半夜有人手工跑一条 UPDATE，第二天业务方问怎么回事”的情况，触发器几乎是唯一能回答这种问题的工具。
2.4 BEFORE 还是 AFTER：我自己的选择标准
创建触发器时会先写BEFORE或AFTER，这两者的差异不是“前”和“后”这么简单。我的选择标准就一句：
需要回写数据本身，用 BEFORE；需要记录已有结果，用 AFTER。
| 时机 | 适用动作 |
|---|---|
| BEFORE INSERT | 校验必填字段、生成默认值、修改即将写入的数据 |
| AFTER INSERT | 写审计表、同步下游表、更新统计表 |
| BEFORE UPDATE | 更新统一时间戳、对 NEW 字段做二次修正 |
| AFTER UPDATE | 记录变更前后差异、级联更新其他表 |
| BEFORE DELETE | 备份即将删除的数据到回收表 |
| AFTER DELETE | 清理关联表、记录删除痕迹 |
举一个反直觉的例子：如果你在触发器里调用了NEW.id，BEFORE INSERT 阶段拿到的不一定是最终自增 ID，而 AFTER INSERT 阶段一定是。因为自增列是在写入那一步才分配的，BEFORE 阶段还没真正落盘。想管数据本身，就在 BEFORE 阶段改；想读最终结果，就放到 AFTER 阶段读。
3. NEW 和 OLD 的读取规则：触发器里最容易绕晕的一对变量
3.1 先看这张可用性表
触发器里有两个虚拟行变量：NEW代表新数据，OLD代表旧数据。它们在不同事件里的可用性完全不一样，这是新手最容易搞混的地方。我把规则整理成了表：
| 事件 | NEW | OLD |
|---|---|---|
| INSERT | 可用，未落盘（BEFORE），或已落盘（AFTER） | 不可用 |
| UPDATE | 可用，代表更新后的新值 | 可用，代表更新前的旧值 |
| DELETE | 不可用 | 可用，代表即将删除的旧值 |
注意 UPDATE 事件里，NEW和OLD是同时存在的一组记录。比如UPDATE orders SET status = 2 WHERE id = 1;执行时，OLD.status是更新前的旧状态，NEW.status是更新后的新状态。这也是审计场景能记录变更差异的原因。
还有个很容易被忽略的细节：OLD只能读，永远不能修改；NEW在 BEFORE INSERT 和 BEFORE UPDATE 事件中可以修改，修改后的值会真正写进表里，但在 AFTER 阶段再改就来不及了，因为数据已经落盘。所以那些要强制“时间戳统一”的逻辑，必须放在 BEFORE 里。
3.2 触发器里取自增 ID，别用 LAST_INSERT_ID()
很多同学在 INSERT 触发器里想拿刚插入的主键，第一反应是调用LAST_INSERT_ID()。这个函数在普通 INSERT 后面用没问题，但在触发器里用非常不可靠。原因是：LAST_INSERT_ID()返回的是当前连接最近一次自动生成的自增 ID，如果这个连接之前还插过其他表，拿到的可能根本不是当前这条记录；如果触发器内部又执行了对其他自增表的 INSERT，值还会被再次覆盖。
正确做法是直接用NEW.id。在 AFTER INSERT 触发器里，NEW.id就是落盘后的真实主键，准确、直接、无副作用。举个例子：
DELIMITER $$ CREATE TRIGGER trg_orders_insert_audit AFTER INSERT ON orders FOR EACH ROW BEGIN INSERT INTO order_operation_log(order_id, action, action_time) VALUES (NEW.id, 'INSERT', NOW()); END$$ DELIMITER ;这里只有用NEW.id才是对的。用LAST_INSERT_ID()在单条插入的场景可能碰巧也能跑出正确结果，但一旦遇到批量 INSERT、多条连接复用，就会出现日志表里的 order_id 跟实际订单对不上的情况。我在项目里排查过这种问题，最后定位到就是这样的隐形依赖，非常隐蔽。
3.3 BEFORE UPDATE 阶段修改 NEW 字段的一个实际需求
前几年做一个数据迁移项目，发现很多老业务表的更新时间字段没有统一规范。有的表靠ON UPDATE CURRENT_TIMESTAMP，有的表是普通 DATETIME，应用层忘记更新了，字段就永远停在创建时间。
当时我给一部分表做了统一回填，核心逻辑就放在 BEFORE UPDATE 触发器里：
DELIMITER $$ CREATE TRIGGER trg_orders_force_update_time BEFORE UPDATE ON orders FOR EACH ROW BEGIN SET NEW.updated_at = CURRENT_TIMESTAMP; END$$ DELIMITER ;这个触发器的作用是：不管应用层有没有传updated_at，只要 UPDATE 语句真的改了这条数据，时间戳就会被强制刷新为当前时间。BEFORE 阶段修改NEW字段是合法且有效的，这是触发器少有的能“在数据写入前纠正数据”的能力。
这里有一个使用误区需要提醒：如果应用层特意想把updated_at改成过去某个时间，比如回填历史数据，那触发器会直接覆盖这个意图。所以强制回填类的触发器不适合放在所有表上，更适合放在那些只允许实时更新的核心业务表上。
4. 数据校验与级联统计：两个可复制的进阶场景
4.1 自动生成业务编号：用计数器表代替 MAX+1
如果业务编号的规则是“日期+当日流水号”，比如20250318-000001，很多人第一反应是写一个触发器查当前表最大的编号再加一，我强烈不建议这么做。原因很简单：并发条件下，两个事务可能同时查到同一个最大值，然后生成重复编号。而且 INSERT 触发器里查当前操作表也不是个干净路子，容易引发锁竞争。
我的做法是单独维护一张计数器表，结合LAST_INSERT_ID(expr)这个特殊用法来生成序号：
CREATE TABLE `order_seq` ( `biz_date` DATE NOT NULL COMMENT '业务日期', `seq` INT UNSIGNED NOT NULL COMMENT '当日流水号', PRIMARY KEY (`biz_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单编号计数器';触发器写成这样：
DELIMITER $$ CREATE TRIGGER trg_orders_gen_no BEFORE INSERT ON orders FOR EACH ROW BEGIN INSERT INTO order_seq(biz_date, seq) VALUES (CURDATE(), 1) ON DUPLICATE KEY UPDATE seq = LAST_INSERT_ID(seq + 1); SET NEW.order_no = CONCAT( DATE_FORMAT(CURDATE(), '%Y%m%d'), '-', LPAD(LAST_INSERT_ID(), 6, '0') ); END$$ DELIMITER ;这段逻辑的精妙之处在于：LAST_INSERT_ID(seq + 1)可以主动把会话的 LAST_INSERT_ID 设置为表达式结果，然后触发器里再用LAST_INSERT_ID()取回。整个过程依赖biz_date主键上的行锁，两个事务同时插入时，一个会等待另一个提交，从而保证序号不会重复。这是 MySQL 里做并发安全序列的经典手法，比查 MAX 靠谱得多。
4.2 维护一张统计表：把“每次查询实时统计”改成“写入时增量统计”
统计需求也适合交给触发器，尤其是那种每天都要看、数据量又特别大的场景。与其每次查询都跑一遍GROUP BY COUNT，不如在写入时就把计数累加好。我做过一个商品日统计表，每次订单表有状态变为“已完成”，对应统计表的已完成数就加一。
先建统计表：
CREATE TABLE `order_daily_stat` ( `stat_date` DATE NOT NULL, `status` TINYINT NOT NULL, `cnt` INT UNSIGNED NOT NULL DEFAULT 0, PRIMARY KEY (`stat_date`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单日统计表';然后建 UPDATE 触发器：
DELIMITER $$ CREATE TRIGGER trg_orders_stat AFTER UPDATE ON orders FOR EACH ROW BEGIN IF OLD.status <> NEW.status THEN INSERT INTO order_daily_stat(stat_date, status, cnt) VALUES (CURDATE(), NEW.status, 1) ON DUPLICATE KEY UPDATE cnt = cnt + 1; END IF; END$$ DELIMITER ;这个逻辑在订单量大的时候效果非常明显：查询端永远只查一张极小的统计表，哪怕主表有几百万行，统计也毫秒级返回。代价是每一笔订单更新时多执行一次累加。对于大多数业务系统来说，写多读少的累加代价完全可以接受，而查询性能收益则是实打实的。
4.3 触发器里的异常处理：没有捕获就是整个事务回滚
触发器里也可以用DECLARE ... HANDLER来做异常处理。声明一个 EXIT HANDLER，碰到异常就执行一段逻辑：
DELIMITER $$ CREATE TRIGGER trg_orders_safe_audit AFTER UPDATE ON orders FOR EACH ROW BEGIN DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN SET @audit_fail = @audit_fail + 1; END; INSERT INTO order_change_log(order_id, old_status, new_status) VALUES (NEW.id, OLD.status, NEW.status); END$$ DELIMITER ;不过我得提醒一句：如果没有声明 HANDLER，触发器里任何一个 SQL 报错，都会导致发起它的那条主语句回滚。也就是说，审计表写入失败，订单状态更新也会一起失败。这不是“日志丢了无所谓”，而是“日志失败拖垮主业务”，很多人没意识到这一点。所以那些“必须保证主表操作成功，日志允许丢失”的场景，就不应该用触发器硬做，可以考虑改成应用层异步日志，或者 MQ 异步落库。
5. 我踩过的三个坑：递归触发、批量操作和字符集
5.1 递归触发：主表 DELETE 跑了二十分钟
有一年做一个清理历史数据的任务，在 DELETE 一张带子表关联的业务表时，发现 SQL 执行了二十分钟都没结束。一开始以为是大表锁竞争，后来打开慢查询日志一看，会话在反复执行同一段删除逻辑。问题就出在：父表上有一个 AFTER DELETE 触发器，会删除子表关联数据，而子表上又一个触发器，删除后回去 DELETE 父表，于是两个触发器互相调用，形成死循环。
MySQL 对触发器的递归不是完全禁用的，至少在旧版本里你可以在触发器里继续做同类型 DML，系统不会主动拦截。一旦逻辑设计出了问题，循环调用就会一直在连接里消耗资源。
我的经验原则是：一个触发器的动作源表和目标表，不允许互相指向。比如 orders 表的触发器去写 order_change_log，这是单向的；但如果 order_change_log 上又有触发器回头更新 orders，这种链路必须拆开。另外，很多团队会用会话变量做防重入标记：
SET @disable_sync = 1; UPDATE orders SET status = 2 WHERE id = 1; SET @disable_sync = 0;然后在触发器里判断：
IF @disable_sync IS NULL OR @disable_sync = 0 THEN -- 正常执行同步逻辑 END IF;但这只能防住应用层主动设置的场景，防不住手工执行的 DML，所以最稳妥的还是结构上不要设计环形链路。
5.2 批量导入的杀手级性能问题
触发器是按行执行的。这意味着一条UPDATE如果匹配了 10000 行，触发器里的逻辑就会执行 10000 次，每次都可能附带一次 INSERT 或 UPDATE。做一次数据初始化，导了几万行，结果每个主表触发器都拖出几条附加 SQL，整体耗时直接从分钟级拉长到小时级。
MySQL 不像某些数据库那样提供现成的DISABLE TRIGGER命令。在 MySQL 里，唯一的干净方案是：批量导入前先 DROP 目标表上的触发器，导入完成后再重新创建。这个操作要在窗口期做，并且脚本要前后幂等。我一般把建触发器的 SQL 单独存成文件，导入脚本里先执行DROP TRIGGER IF EXISTS，导入完再source创建文件，这样流程可重复、可回滚。
5.3 字符集不一致导致写入失败
有次在触发器里写审计日志，插入包含中文的字段时直接报Incorrect string value，错误码 1366。查了一圈，主表是 utf8mb4，日志表也是 utf8mb4，看起来没毛病。最后定位到问题其实出在创建触发器时的连接字符集上。当时用的是某个旧版管理工具，会话默认字符集是 latin1，导致触发器定义里的字符串字面量都按 latin1 编译了，运行时再往 utf8mb4 表里写就报错。
解决办法很朴素：创建触发器前先执行SET NAMES utf8mb4;，然后重新创建。如果你的业务还用到 emoji，那更要确认连接字符集、表字符集、触发器定义字符集三者统一。这个坑不算高频，但一旦触发，排查方向很容易跑偏。
5.4 从库重复触发问题和检查习惯
主从复制环境里，触发器还有一个容易被忽略的坑：基于语句的复制会把触发器产生的变更也复制到从库，如果从库上还保留着同名的业务触发器，那么日志可能被写两次。基于行的复制规则有所不同，但为了统一运维习惯，我现在的原则是：从库只做查询和备份，不在从库上建业务触发器。需要对账的场景，直接查信息表或者用独立的数据校验脚本，而不是在从库重复挂逻辑。
这也延伸出一个检查习惯：每次巡检，我都会用SHOW TRIGGERS扫一遍实例，确认每个触发器还有存在价值，把没有注释的旧逻辑翻出来补说明。触发器比存储过程藏得更深，代码评审里根本不会出现，如果没有注释，半年后回头看就是天书。
6. 触发器的管理命令和版本差异
6.1 查看触发器：三条命令
管理触发器没有太多花哨手段，最常用的是下面几条：
SHOW TRIGGERS; SHOW CREATE TRIGGER trg_orders_audit;第二条能直接看到触发器的定义语句，包含主体代码，排错的时候最有用。如果想从元数据维度筛触发器，可以用 information_schema：
SELECT TRIGGER_NAME, EVENT_MANIPULATION, EVENT_OBJECT_TABLE, ACTION_TIMING, ACTION_STATEMENT FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_SCHEMA = 'demo_db';在 MySQL 8.0 里，SHOW CREATE TRIGGER和 information_schema 都支持得很好。我在 5.7 的老环境里也验证过，基本逻辑一致，只是某些输出字段略有差异，写脚本做快照对比时以TRIGGER_NAME + ACTION_STATEMENT为准会稳一点。
查看命令解决的基本问题有两个：一是确认触发器存在，二是确认触发器的逻辑没有被别人悄悄改过。我见过团队里有人为了排查线上数据问题，直接在共享数据库里 DROP 掉一个触发器，事后没重建，然后过了三星期才发现业务数据异常。所以查看触发器的时候，最好也顺手把当前存在的触发器清单导出来存档，用于变更比对。
6.2 修改触发器：没有 ALTER，只有 DROP 后再 CREATE
MySQL 没有提供 ALTER TRIGGER 的语法，想改一个触发器，只能先 DROP 再重建。这很反直觉，也容易在操作时造成空窗期：
DROP TRIGGER IF EXISTS trg_orders_audit;如果 DROP 之后重建语句在保存或执行时报错，那这段时间里这个触发器就彻底不存在了，所有依赖它的逻辑会静默失效。所以我的习惯是：修改前先SHOW CREATE TRIGGER拿到完整定义存到脚本文件里，新版本同样存文件，两步走。绝对不要直接在线上编辑器里敲 DROP。
另外，DROP TRIGGER需要表的 DROP TRIGGER 权限，创建触发器需要 TRIGGER 权限。给应用账号授权的时候，我默认会收回这两个权限，避免应用层随意创建或删除触发器。数据库对象变更应该走发布流程，不能跑在业务代码里。
6.3 触发器导致慢 SQL 的排查思路
触发器把逻辑藏在了主语句后面，所以慢 SQL 排查往往要先“拆盲盒”。我总结的排查思路是这样的：
- 先看慢查询日志里那条异常的 UPDATE 或 DELETE，拿到执行时间和受影响行数。
- 用
SHOW CREATE TRIGGER查看这张表上挂了哪些触发器。 - 把触发器里涉及的 INSERT、UPDATE、SELECT 单独拆出来，用 EXPLAIN 看执行计划。
- 尤其注意触发器里有没有查大表、有没有用到全表扫描、有没有在循环里重复查同一张表。
实际操作中，最影响性能的通常是触发器里的 SELECT，因为每行数据变更都会触发一次查询。比如有的开发会在 UPDATE 触发器里重新查一遍订单表来计算某些字段，数据量一大就线性恶化。优化思路很直接：能用 NEW 和 OLD 拿到的值，就不要再去查表；必须查询的，确保索引能命中。
6.4 5.7 与 8.0 的兼容性注意点
如果你在维护存量系统，还得注意版本差异。MySQL 8.0.16 之后原生 CHECK 约束默认启用了，以前很多项目习惯用触发器模拟字段取值范围的校验，现在这些完全可以简化成原生 CHECK 约束，触发器要拆掉，否则两套逻辑叠加，反而造成重复校验和性能浪费。
另外，MySQL 8.0 对触发器主体的限制更严格，比如不允许LOAD DATA等语句出现在触发器里，遇到旧脚本迁移到 8.0 时，建议先把所有触发器定义导出来，在测试环境完整跑一遍批量回归。我见过一个旧系统，触发器里用了老语法，8.0 环境下创建成功但执行时行为不一致，最后只能逐个改写成新写法。这种事没有什么技巧，就是提前建一套触发器回归清单，覆盖每个表的增删改路径，做一次全量验证。
7. 从实际项目中总结的触发器使用原则
最后分享几条我在实际项目里沉淀下来的原则，算是给这篇画个句号。
第一，触发器永远是“最后选择”，不是“第一选择”。凡是应用层能干净解决的逻辑，就不要塞进数据库。应用层代码能评审、能测试、能灰度发布，触发器这些统统很难做。选择触发器，应该是出于事务一致性和侧强制约束的考虑，而不是因为写应用层麻烦。
第二，触发器必须小而快。一个触发器里不要有多段复杂业务，不要调外部接口，不要执行大面积更新。触发器的本质是主语句的附属品，主语句性能不能被拖垮。我在实践中会把“触发器内 SQL 数量不超过两三条”当作一条硬标准。
第三，所有触发器都要写注释。用COMMENT字段描述它的目的、触发场景、变更人、变更时间。没有注释的触发器，三个月后就是事故地雷。我见过最痛苦的一次排障，就是为了弄明白一个几年前加的 UPDATE 触发器到底为什么要做那步冗余更新，最后要靠翻提交记录才找到线索。触发器藏得很深，注释不写清楚，谁都不敢动它。
如果你今天只记住一件事，那就记住这句话：触发器该用的时候，它是数据库最后一道防线；不该用的时候，它就是下一个让你彻夜加班排障的暗坑。用它之前先想清楚边界，用它之后记得留好注释。
