触发器能替代应用层逻辑吗？别轻易这么想
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，在开发环境可能走触发器，在测试环境可能因权限或配置被跳过。上线前务必在真实部署拓扑里跑端到端验证，而不是只测单条语句。
