触发器不能替代应用层逻辑，仅适用于数据库强约束或自动补全（如更新时间、字段校验、审计日志）；禁止在其中调用外部API或做复杂权限判断，否则引发性能与可维护性问题。
触发器能替代应用层逻辑吗？别轻易这么想
MySQL 触发器不是业务逻辑的“兜底方案”，它只适合做数据库层面的强约束或自动补全，比如自动生成 updated_at、校验跨字段逻辑（如 end_time > start_time）、同步写入审计日志表。一旦你试图用 BEFORE INSERT 去调用外部 API 或做复杂权限判断，就踩进了性能和可维护性陷阱——触发器内无法回滚外部操作，也查不到应用上下文（如当前用户 ID），调试时连 SELECT 都受限。
INSERT 和 UPDATE 触发器里，NEW 关键字到底怎么用
NEW 是触发器中访问即将插入/更新行数据的唯一方式，但它在 BEFORE 和 AFTER 中行为不同：
-
BEFORE INSERT：可读可写NEW.column_name，改了就会真正插入修改后的值； -
BEFORE UPDATE：同理，改NEW.updated_at会生效，但不能改NEW.id（主键）； -
AFTER类型触发器中，NEW只读，且此时记录已落盘，再改无意义； - 注意：
OLD在UPDATE和DELETE中才可用，INSERT没有OLD。
DELIMITER $$ CREATE TRIGGER users_set_updated_at BEFORE UPDATE ON users FOR EACH ROW BEGIN SET NEW.updated_at = NOW(); END$$ DELIMITER ;
触发器报错 “Can't update table 'xxx' in stored function/trigger” 怎么解
这是 MySQL 的硬限制：触发器里不能对**当前正在被修改的表**执行 INSERT/UPDATE/DELETE，否则会死锁。常见误用包括：
- 在
users表的BEFORE INSERT里又去INSERT INTO users（递归）； - 想用触发器实现“插入 A 表时自动插入 B 表 + 更新 A 表某字段”，结果在触发器里写了
UPDATE A； - 跨库操作时路径写错，比如
mydb.users被解析成当前库下表，仍触发限制。
解法只有两个：要么把逻辑提到应用层，要么用 AFTER INSERT 改其他表（非本表），且确保不反向触达原表。
触发器没生效？先查这三件事
线上发现触发器像没存在一样，大概率卡在这几个点：
- MySQL 版本低于 5.0.2 —— 触发器从这个版本才正式支持；
- 创建时没加
DELIMITER，导致分号提前结束语句，实际只建了个空触发器； - 用户权限不足：
TRIGGER权限是独立授予的，GRANT TRIGGER ON mydb.* TO 'user'@'%'必须显式执行。
验证是否启用：运行 SHOW TRIGGERS LIKE 'users';，空结果不一定是没建，也可能是权限不够看不到。
触发器真正的难点不在语法，而在于它隐式改变了 SQL 的行为边界——同一句 INSERT，在开发环境可能走触发器，在测试环境可能因权限或配置被跳过。上线前务必在真实部署拓扑里跑端到端验证，而不是只测单条语句。
