MySQL 触发器怎么排查重复写入：执行时机、递归风险与审计表核对

审计表突然多出两条相同记录时，触发器确实值得查，但它通常不是唯一嫌疑。MySQL 触发器按行响应 INSERT、UPDATE、DELETE；同一张表还可能挂着多个相同事件和时机的触发器。排查的关键，是把“一个业务请求写了几次”和“一个写入触发了几次附加动作”分开核对。

先用 SHOW TRIGGERS 列出对象，再用 SHOW CREATE TRIGGER 看完整定义，最后用一笔可回滚的最小写入核对审计表增量。只有这三步结果能对上，才适合改触发器。

先把“重复”拆成两种现象

假设业务表是 orders，审计表是 order_audit。同一订单出现两条相同审计记录，至少有两条路径：

• 应用真的发出了两次 INSERT，两个 INSERT 各自触发一次审计。
• 应用只发出一次 INSERT，但表上存在两个都响应 INSERT 的触发器，或者触发器链路又写入了另一张带触发器的表。

这两种问题的修法完全不同。第一种要查请求重试、消息消费和幂等键；第二种才是数据库对象或写入链路的问题。不要看到审计表重复就直接执行 DROP TRIGGER。

用元数据确认到底挂了哪些触发器

先在目标库执行：

SHOW TRIGGERS FROM shop\G
SHOW CREATE TRIGGER shop.trg_orders_audit\G

第一条适合快速查看表名、事件和时机；第二条才是完整定义，包含触发器主体、定义者和字符集等信息。重点记录四个字段：Trigger、Event、Timing、Statement。如果同一张表出现两个 INSERT + AFTER 组合，重复审计就有了直接线索。

MySQL 8.4 支持同一张表拥有多个相同事件和动作时机的触发器，所以不能只凭“我记得已经建过一个”下结论。把输出保存到变更单，尤其注意是否有同名对象来自不同 schema。

执行时机决定你能看到什么结果

BEFORE 触发器发生在行操作前，适合校正待写入值或做前置校验；AFTER 触发器只有在前置触发器和行操作都成功后才会继续。两者出错都会让触发它的整条语句失败，事务型表的变更也会随语句失败回滚。

这解释了一个常见误判：应用日志里显示“插入失败”，但审计表里却看到了记录。需要确认审计表是否与业务表同属事务型存储引擎，以及审计动作是否落在同一事务边界内。不要把一次失败重试留下的记录，简单归因于 AFTER 本身。

另外，触发器是 FOR EACH ROW，批量插入 100 行时，触发器主体可能运行 100 次。审计表按订单号聚合时，批量语句带来的多条合法记录也可能被误看成重复。

用一笔最小写入区分数据库和应用问题

在测试库准备一个不会影响真实订单的样例，先记录审计表数量，再只写入一行：

START TRANSACTION;
SELECT COUNT(*) AS before_count
FROM order_audit
WHERE order_id = 900001;

INSERT INTO orders(order_id, buyer_id, amount)
VALUES (900001, 21, 19.90);

SELECT COUNT(*) AS after_count
FROM order_audit
WHERE order_id = 900001;
ROLLBACK;

如果一次 INSERT 让审计行增加两条，继续对照所有相关触发器的主体；如果只增加一条，而线上出现两条，就该转向应用日志、消息投递次数和唯一约束检查。这里要看“增量”，不要只看最终总数。

若触发器写入的是另一张带触发器的表，再沿着 INSERT、UPDATE 目标表继续展开。MySQL 不支持在触发器中直接调用会返回客户端数据或使用动态 SQL 的存储过程，也不允许在触发器里显式开始或结束事务；这些限制可以帮助缩小链路范围。

递归风险和权限问题要单独确认

真正危险的不是“触发器存在”，而是触发器写回同一条业务链，导致重复动作难以从日志中区分。把审计表设计成只追加、无业务触发器的落点，通常比让审计表继续触发业务逻辑更容易验收。

还要检查定义者权限。创建触发器需要目标表的 TRIGGER 权限，触发时使用定义者安全上下文；定义者权限被撤销后，原来正常的写入也可能开始报错。可用下面的语句核对定义：

SHOW CREATE TRIGGER shop.trg_orders_audit\G
SHOW GRANTS FOR 'audit_owner'@'%';

不要在生产环境为了“验证一下”临时提升权限。先复制定义和权限现状，再在隔离环境复现，最后用一笔成功写入和一笔预期失败写入反向验收。

常见误区：把清理数据当成修复

只删除重复行，不保留触发器定义

删除数据只能恢复表面数量，不能解释重复来源。至少保留触发器定义、相关表结构、请求标识和复现前后计数。

看到两个触发器就认定它们重复

同一表上的多个触发器可能分别负责审计、更新时间或校验。要看事件、时机和主体是否写入同一目标，不要只按名称判断。

线上直接禁用对象观察

MySQL 没有适合所有场景的一键“暂停触发器”开关。生产变更应走明确的发布和回滚路径，先在影子库或低风险表验证影响。

延伸问答

批量 INSERT 为什么会生成很多审计行？

因为触发器按行执行，批量语句中的每一行都会单独触发。先确认业务上是否应该逐行留痕，再决定审计表的唯一键或批次字段。

应用重试怎样避免重复审计？

在业务写入上使用幂等键或唯一约束，并把请求 ID 写入审计表。触发器只能观察已经发生的行变化，不能替代完整的请求幂等设计。

什么时候不适合用触发器做审计？

当审计需要跨服务、异步补偿、复杂上下文或长时间保留调用方身份时，应用事件或专门的变更日志通常更容易追踪。触发器更适合简单、同库、同事务边界内的记录。

收尾核对清单

遇到重复写入，按“列对象—看定义—做最小复现—查应用重试—核对权限”的顺序处理。修复后再次执行同一笔测试，确认审计增量符合预期，再把线上请求 ID、触发器版本和回滚方案补进变更记录。这样即使问题再次出现，也能快速判断是数据库对象变化，还是调用方重复提交。