MySQL 触发器只能作用在
INSERT、
UPDATE和
DELETE这三类 DML 操作上，不支持 SELECT、TRUNCATE、ALTER、DROP 等其他语句触发。这是硬性限制，不是配置问题。
哪些操作能触发 MySQL 触发器？
只有对表执行以下三种显式数据变更操作时，才会激活对应触发器：
INSERT：包括
INSERT INTO ... VALUES、
INSERT INTO ... SELECT（但注意：
INSERT ... ON DUPLICATE KEY UPDATE会触发
BEFORE INSERT和
AFTER INSERT，而冲突走
UPDATE分支时还会额外触发
BEFORE UPDATE/
AFTER UPDATE）
UPDATE：哪怕 SET 的值和原值完全相同（如
UPDATE t SET x=5 WHERE id=1，而 x 原本就是 5），只要语句执行成功，就会触发 —— MySQL 不做“实际变更”判断
DELETE：包括
DELETE FROM和
TRUNCATE—— 但注意：
TRUNCATE是 DDL 操作，**不会触发任何 DELETE 触发器**，这点极易踩坑
为什么 TRUNCATE 不触发 DELETE 触发器？
因为
TRUNCATE在 MySQL 中本质是「重建表」：它先删掉原表文件，再用空结构重建，绕过了逐行处理逻辑。所以即使你写了
AFTER DELETE触发器，
TRUNCATE table_name也完全无视它。 ✅ 正确做法：真要清空并触发逻辑，改用
DELETE FROM table_name⚠️ 风险提示：大表用
DELETE可能锁表久、生成大量 binlog；若必须用
TRUNCATE，需手动补全触发器该做的事（比如清空日志表、重置计数器等） ? 验证方式：执行
SHOW TRIGGERS LIKE 'your_table'，确认触发器类型是否为
DELETE，再测试
TRUNCATE是否无反应
BEFORE vs AFTER：时间点决定你能做什么
触发时机直接约束你能访问和修改的数据范围：
BEFORE INSERT：可用
NEW.col = ...修改即将插入的值（比如自动补
created_at、校验
OLD（不存在）
BEFORE UPDATE：可读
OLD.col（原值）、写
NEW.col（新值）；适合做字段级审计（如记录谁改了价格）、拦截非法更新（如
IF NEW.price > OLD.price * 1.1 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '涨价超10%禁止'; END IF;）
AFTER DELETE：只能读
OLD.col（被删行的最后快照），适合写归档、发通知、清理关联缓存；但此时行已不存在，不能再对原表做
UPDATE同一主键（会报错）
常见误用场景与后果
这些操作看似合理，实则 MySQL 明确禁止，会直接报错：
在触发器里执行INSERT/UPDATE/DELETE当前触发器所属的同一张表（即“递归修改自身表”）→ 报错
ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger.在
BEFORE触发器中对
NEW赋值一个非法类型（如给
INT字段赋字符串
'abc'）→ 触发器执行失败，整个原始语句回滚 在触发器里调用存储函数，而该函数又尝试修改表 → 同样触发 1442 错误（MySQL 对“表依赖链”有严格静态检查）
DELIMITER //
CREATE TRIGGER check_price_before_update
BEFORE UPDATE ON products
FOR EACH ROW
BEGIN
IF NEW.price < 0 THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Price cannot be negative';
END IF;
-- ✅ 允许：修改 NEW 值
SET NEW.updated_at = NOW();
END //
DELIMITER ;触发器不是万能钩子，它的能力边界非常清晰：只响应那三个动词、只在行级生效、不能碰自己表、不感知事务外操作。真正难的从来不是写出来，而是想清楚——这件事非得靠触发器做不可吗？很多业务逻辑放在应用层更可控、更易测、更易排查。
