触发器的三个事件分别对应INSERT、UPDATE、DELETE操作:INSERT触发于INSERT/REPLACE/LOAD DATA;UPDATE仅在字段值实际变化时触发;DELETE不响应TRUNCATE(DDL,不触发)。

触发器的三个事件分别对应什么操作
MySQL 触发器的 INSERT、UPDATE、DELETE 是指在对表执行这三类 DML 操作时自动触发的时机,不是“可以随便选”的选项,而是严格绑定到实际语句行为上:
-
INSERT触发器:仅当执行INSERT INTO ...或REPLACE INTO ...(本质含 DELETE + INSERT)时触发;LOAD DATA INFILE也会触发,但需注意LOCAL是否启用影响权限路径 -
UPDATE触发器:只响应字段值真正发生变化的行——即使写了UPDATE t SET x=1 WHERE id=1,但如果当前x已是1,该行不会触发BEFORE UPDATE或AFTER UPDATE -
DELETE触发器:对DELETE FROM和TRUNCATE TABLE行为不一致——TRUNCATE是 DDL,**完全不触发任何 DELETE 触发器**,这是高频踩坑点
BEFORE 和 AFTER 在不同事件下的限制与用途
每个事件都可配 BEFORE 或 AFTER,但作用差异极大,且有硬性约束:
-
BEFORE INSERT:可修改NEW中的字段值(比如自动生成created_at或校验逻辑),但不能读写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 需记录每次邮箱变更的历史,且禁止将邮箱设为空字符串:
DM建站系统律师事务所HTML5网站模板, DM企业建站系统。是由php+mysql开发的一套专门用于中小企业网站建设的开源cms。DM系统的理念就是组装,把模板和区块组装起来,产生不同的网站效果。可以用来快速建设一个响应式的企业网站( PC,手机,微信都可以访问)。后台操作简单,维护方便。DM企业建站系统安装步骤:第一步,先用phpmyadmin导入sql文件。 第二步:把文件放到你的本地服务器
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 ;
注意这里用了 SIGNAL 主动报错中断,比事后查日志更可控;IF NEW.email != OLD.email 判断避免无意义插入——哪怕字段类型是 VARCHAR,也要小心 NULL 与空字符串的比较行为。
真正难的不是写语法,而是想清楚“这一行变化是否真的需要立刻同步”,以及“如果触发器失败,业务能否接受整条语句失败”。









