触发器的三个事件：不只是选项，更是严格绑定

在MySQL中，INSERT、UPDATE、DELETE这三个触发器事件，与具体的DML操作行为严格绑定。

它们的触发时机有着明确的规则。

INSERT触发器

INSERT触发器只在执行INSERT INTO ...这类插入语句时被唤醒。

需要注意两个细节：

• REPLACE INTO ...语句会触发INSERT事件。
• 使用LOAD DATA INFILE批量导入数据时同样会触发。

UPDATE触发器

UPDATE触发器只响应字段值真正发生了变化的行。

即使执行了UPDATE语句，如果字段值未变，也不会触发BEFORE UPDATE或AFTER UPDATE。

这个特性在优化性能时很有用。

DELETE触发器

DELETE FROM语句会正常触发DELETE触发器。

但需要特别警惕：TRUNCATE TABLE操作完全不会触发任何DELETE触发器。

这是很多开发者容易踩坑的地方。

BEFORE与AFTER：时机不同，约束迥异

每个事件都可搭配BEFORE或AFTER，但作用和限制差异巨大。

BEFORE INSERT触发器

你可以修改即将插入的NEW虚拟行中的字段值。

例如，自动填充创建时间戳或进行数据校验。

此时你无法访问OLD，因为数据尚未插入。

BEFORE UPDATE触发器

你既可以读取变化前的OLD值，也可以修改即将写入的NEW值。

这使得它非常适合实现字段变更审计，或在级联更新前进行逻辑拦截。

AFTER DELETE触发器

它能安全地访问已被删除行的OLD数据。

常用于写入审计日志或清理关联的缓存数据。

注意：此时原表中的该行数据已经消失，无法在触发器内进行恢复。

关键限制

在AFTER INSERT和AFTER UPDATE触发器中，禁止修改NEW字段值。

否则会引发Can‘t update table ’t‘ in stored function/trigger错误。

数据已经落盘，触发器的工作更多是“事后响应”。

那些容易被忽视的陷阱：跨表、事务与性能

触发器用起来方便，但容易引入棘手问题。

陷阱一：链式触发与死循环

在触发器内部执行INSERT INTO other_table属于隐式的跨表写入。

如果目标表上也有同名触发器，就可能引发链式触发，甚至导致死循环。

MySQL本身不做递归深度检查，需要开发者自己把控。

陷阱二：共享事务与回滚

触发器的执行与引发它的主SQL语句共享同一个事务。

一旦触发器内部操作出错，整个原始语句连同触发器内的操作都会一起回滚。

开发者常误以为“只是记录日志失败了，主操作应该成功”，这是一种误解。

陷阱三：性能隐患

在高并发写入的表上设置AFTER UPDATE触发器，去实时更新另一张统计表，可能引发热点锁竞争。

瓶颈可能会从原表转移到统计表上。

对于这类场景，更稳妥的做法是考虑异步落库，或使用物化视图等替代方案。

陷阱四：事务控制限制

MySQL 8.0.16及以上版本支持在触发器中调用存储过程。

但你仍然无法在触发器内部显式地开启或提交事务。

执行START TRANSACTION会报错，所有操作都天然属于外层事务的一部分。

实战：一个安全的UPDATE触发器示例

假设有一个用户表users，需要记录每次邮箱变更历史，并禁止将邮箱更新为空字符串。

DELIMITER $$
CREATE TRIGGER users_email_audit
BEFORE UPDATE ON users
FOR EACH ROW
BEGIN
    IF NEW.email != OLD.email THEN
        INSERT INTO email_history (user_id, old_email, new_email, changed_at)
        VALUES (OLD.id, OLD.email, NEW.email, NOW());
    END IF;

    IF NEW.email = '' OR NEW.email IS NULL THEN
        SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Email cannot be empty';
    END IF;
END$$
DELIMITER ;

设计要点解析

• 时机选择：使用BEFORE UPDATE，能在数据变更前校验，同时访问新旧值。
• 避免无效记录：通过IF NEW.email != OLD.email判断，避免邮箱未变化时产生无意义审计记录。需注意NULL值与空字符串的比较行为。
• 主动中断：对于非法数据（空邮箱），使用SIGNAL主动抛出错误，中断整个更新操作，比事后查日志更可控。

编写触发器的语法并不难。

真正的挑战在于想清楚两个问题：

1. 这一行数据的变化，是否真的需要立刻、同步地触发后续操作？
2. 如果这个触发器执行失败了，业务逻辑是否能接受原始的DML语句也一同失败？

把这两个问题考虑周全，才能用好触发器这把双刃剑。