人人都会AI编程

10.3 触发器：触发时机、事件类型、适用场景与缺陷

更新时间：2026-07-10

触发器（Trigger）是数据库层面的一种编程机制，允许你在对表执行 INSERT、UPDATE、DELETE 操作之前或之后，自动执行一段预先写好的 SQL 逻辑。它就像是数据库内部设置的一个“钩子”，当特定事件发生时，被自动触发执行，应用程序无需显式调用。

10.3.1 触发时机与事件类型

触发器的创建语法中，你需要明确指定两个关键要素：触发时机和触发事件。

触发时机决定触发器在 SQL 操作执行前还是执行后运行：

  • BEFORE：在数据即将写入或修改之前触发。常用于数据校验、自动填充字段、对即将插入或更新的数据进行清洗或转换。在 BEFORE INSERT 触发器中，你可以修改 NEW 伪记录的值，这些修改会直接写入表中。
  • AFTER：在数据已经写入或修改之后触发。常用于审计日志记录、更新汇总统计、发送通知等后续操作。此时数据已经落地，不能再修改 NEW 值，但可以访问 NEW 和 OLD 伪记录来记录变化前后的值。

触发事件即哪类 SQL 操作会激活触发器：

  • INSERT：当向表中插入新行时触发。此时 NEW 代表要插入的行，BEFORE INSERT 中可修改它；AFTER INSERT 中只能读取。
  • UPDATE：当表中的行被修改时触发。此时 OLD 代表修改前的行值，NEW 代表要变成的行值。在 BEFORE UPDATE 中可以修改 NEW，在 AFTER UPDATE 中可以同时读取两者。
  • DELETE：当表中的行被删除时触发。此时 OLD 代表被删除的行值，没有 NEW。

一个触发器只能关联一个表的一种事件和一种时机，比如“在 orders 表的 INSERT 之前”。如果你需要在同一个表的 INSERT 和 UPDATE 上同时使用相同逻辑，就需要创建两个触发器。

一个简单的示例——在 user 表插入前自动生成创建时间字段值：

CREATE TRIGGER trg_user_before_insert
BEFORE INSERT ON user
FOR EACH ROW
BEGIN
    SET NEW.create_time = NOW();
END;

需要注意，MySQL 的触发器是基于行的（FOR EACH ROW），即如果一条 SQL 语句影响了多行（比如 UPDATE ... WHERE id IN (1,2,3)），那么触发器会为每一行分别执行一次。这个特性对性能有直接的影响，后面会细说。

10.3.2 触发器内的可访问数据

在触发器体内，你可以使用 NEW 和 OLD 关键字来引用数据：

  • NEW.column_name：INSERT 或 UPDATE 事件中的新行列值。在 BEFORE 触发器内可以修改，在 AFTER 中只能读取。
  • OLD.column_name：UPDATE 或 DELETE 事件中的旧行列值。在 BEFORE 或 AFTER 中均为只读。

另外，MySQL 的触发器有一些重要的限制：

  • 不能使用 SHOW、SET autocommit、COMMIT、ROLLBACK 等直接改变事务状态的语句。
  • 不能使用动态 SQL（例如通过 PREPARE 执行拼接的 SQL 字符串），这意味着触发器逻辑必须是静态的。
  • 不允许在触发器中显式修改当前触发它的表（即不能在同一个表上执行 INSERT/UPDATE/DELETE），但可以通过 BEFORE 触发器修改 NEW 值间接实现。这主要是为了防止无限递归或死循环。
  • 触发器内的 SQL 语句与原触发语句运行在同一个事务中，因此如果触发器执行失败，原操作也会被回滚。

10.3.3 适用场景

尽管触发器有许多限制和潜在的陷阱，但在某些限定场景下使用得当，可以简化应用逻辑，并保证数据的一致性。

1. 自动生成或修改列值

这是最常见、也最安全的场景。例如自动设定 create_time、update_time，或者根据其他列的值计算衍生字段。这些逻辑简单、确定性高，放在 BEFORE 触发器中比在应用代码里做更可靠，因为任何直接写入这张表的方式（包括运维人员的临时 UPDATE 或数据迁移脚本）都会触发相同的规则，杜绝了绕开业务逻辑的可能。

2. 简易的审计与变更日志

在 AFTER 触发器中将旧值和新值记录到一张审计表中，可以实现数据库级别的操作审计。示例：

CREATE TRIGGER trg_order_after_update
AFTER UPDATE ON orders
FOR EACH ROW
BEGIN
    INSERT INTO orders_audit(order_id, old_status, new_status, changed_at)
    VALUES (OLD.id, OLD.status, NEW.status, NOW());
END;

这种方式的好处是：无论修改来自哪个应用、哪个管理工具，只要数据变化了，审计记录就一定会生成，不容易遗漏。

3. 维护冗余数据或汇总表

在某些性能敏感的场景中，你可能为了加速查询而维护一些冗余数据（比如订单表同时冗余用户昵称、商品名称），或者维护一张实时统计表。通过触发器可以在源表数据变化时自动更新汇总或冗余字段。不过这需要谨慎评估写入性能和锁竞争，一般只有在写入频率适中且实时性要求极高的情况下才会采用。

4. 复杂的字段值校验

CHECK 约束只能做简单的布尔校验，如果校验逻辑需要跨表查询或引用其他表的当前状态，用 BEFORE 触发器实现是一种可行的替代方案。例如，在插入订单时检查用户账户是否处于激活状态：

CREATE TRIGGER trg_order_before_insert
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
    DECLARE user_status INT;
    SELECT status INTO user_status FROM users WHERE id = NEW.user_id;
    IF user_status <> 1 THEN
        SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '用户状态异常，无法下单';
    END IF;
END;

一旦校验失败，通过 SIGNAL 抛出错误，原 INSERT 语句会终止并回滚事务，保证了数据进入前必须满足业务规则。

10.3.4 触发器的主要缺陷与避坑指南

尽管触发器看似能一劳永逸地解决许多问题，但它也是 MySQL 中公认的“双刃剑”，许多资深 DBA 和开发者都建议尽可能少用或不用触发器，原因主要集中在以下几点。

1. 隐式逻辑，调试排查困难

触发器是“隐式”运行的：应用代码发起一个简单的 INSERT，背后可能还执行了触发器中的多个 UPDATE 和 INSERT。这些副作用不在应用代码里可见，对开发和调试非常不友好。一旦出现数据问题，排查链路变长，需要逐一确认每一步触发器做了哪些修改，尤其在多层触发、表之间存在级联逻辑时，数据流向可能变得非常难以追踪。

2. 性能开销显著

MySQL 的触发器是基于行的，一条批量更新语句会影响多少行，触发器就需要执行多少次。假设一个更新操作影响了 10 万行，而你有一个 AFTER UPDATE 触发器，里面写了一个较重的子查询或关联更新，那么这 10 万次触发会严重拖慢整体执行时间，甚至可能导致锁长时间不释放，影响其他并发事务。如果触发器内访问了外部表，还可能引入大量的随机 I/O 和锁竞争。

3. 隐藏的锁与事务风险

触发器内的所有操作与触发它的语句处于同一个事务。这意味着如果触发器执行了一条耗时较长或锁资源较多的语句（比如更新一张大表），那么整个事务的持锁时间变长，增大了死锁概率，也延长了 Undo Log 的持有时间。在可重复读隔离级别下，长事务会导致 Undo Log 无法及时清理，进而引发数据库回滚段膨胀、性能下降。

另外，如果触发器修改了其他表，可能对该表产生意外的锁，甚至形成触发链（A 表触发器修改 B 表，B 表又有触发器修改 C 表，甚至回到 A 表），这种连锁效应极易导致死锁和不可预知的性能问题。MySQL 为了避免无限递归限制了触发器的调用深度（最大 16 层），但即使未达限制，长触发链本身也是设计灾难。

4. 维护负担重，难以迁移

触发器是数据库对象的一部分，存储在内部，版本管理和代码审查都不如应用代码方便。当业务逻辑发生变化时，很可能忘记同步修改触发器，导致新旧逻辑并存产生数据混乱。如果要迁移到其他数据库（如 PostgreSQL、TiDB），触发器语法和行为可能有较大差异，迁移成本会明显升高。

5. 削弱应用层的可控性

一旦把业务规则下沉到数据库触发器，应用层就丧失了对这些规则的精细控制。例如，某些场景下需要跳过触发器逻辑（如数据修正脚本、历史数据迁移），但触发器是强制执行的，除非临时禁用触发器（需要 SUPER 权限），否则很难绕过。这会增加运维操作的复杂度和风险。

10.3.5 合理使用触发器的原则

结合上述分析，实践中使用触发器应遵循一些明确的原则：

  • 能不用就不用。大多数触发器能实现的功能，都可以在应用代码层或通过更好的设计来替代。例如，对于自动更新时间戳，完全可以用 ON UPDATE CURRENT_TIMESTAMP 属性，而非触发器。
  • 如果要用，只用在逻辑极其简单且必须保证任何写入路径都不能遗漏的场景，例如核心审计日志。但即使如此，也要控制触发器内部的 SQL 尽可能简单、只涉及小范围操作，避免关联大表。
  • 严禁在触发器中嵌入复杂业务逻辑、跨多表更新或调用外部资源。触发器应该只做轻量级的、确定性的数据变更，且最好不要操作除审计日志或汇总表之外的其他业务表。
  • 在开发规范中显式记录和评审所有触发器，确保团队成员都清楚它们的存在和影响。
  • 对于高性能要求的批量写入场景，建议评估是否可在应用层合并处理，或者通过消息队列异步实现，而不是在触发器中逐行处理。

总之，MySQL 触发器是一个“小众但存在”的机制。它在特定场景（如审计、数据校验）下确实能起到守门员的作用，但开发者必须认清它的隐性成本：调试难度、性能损耗和可维护性的下降。用它之前，请确保你已经理解了它将在你的系统中引入多大的隐性代价——多数时候，把逻辑放在应用层是更清晰、更可控的选择。