CREATE TRIGGER 语句必须指定触发时机和事件类型
MySQL 触发器不能“随时”执行，必须明确绑定在
INSERT、
UPDATE或
DELETE事件上，并且只能选
BEFORE或
AFTER之一。漏写或写错会直接报错：
ERROR 1064 (42000)。
常见错误包括：把
BEFORE UPDATE写成
ON UPDATE BEFORE（顺序反了），或试图用
SELECT作为触发事件（MySQL 不支持）。触发器主体必须用
BEGIN ... END包裹，且需临时修改分隔符避免与内部
;冲突。
DELIMITER $$ CREATE TRIGGER tr_user_updated_at BEFORE UPDATE ON users FOR EACH ROW BEGIN SET NEW.updated_at = NOW(); END$$ DELIMITER ;
MySQL 不支持 ALTER TRIGGER，修改必须先删后建
这是最容易踩的坑：没有
ALTER TRIGGER语法。想改逻辑、改触发时机、甚至只改名字，都得先
DROP TRIGGER，再重新
CREATE。操作前务必确认当前定义——否则删掉旧触发器却忘了备份逻辑，数据一致性就断了。
查看现有触发器用：
SHOW TRIGGERS LIKE 'users'；更稳妥的方式是查
information_schema.TRIGGERS表，能拿到完整 SQL 定义：
SELECT ACTION_STATEMENT FROM information_schema.TRIGGERS WHERE TRIGGER_NAME = 'tr_user_updated_at' AND EVENT_OBJECT_TABLE = 'users';生产环境建议把触发器 SQL 存进版本控制，而不是靠
SHOW TRIGGERS临场回忆 如果表正在被高并发写入，
DROP + CREATE窗口期可能丢失一次触发，需评估业务容忍度 触发器名在库内全局唯一，重命名本质就是新建一个不同名的触发器
DROP TRIGGER 必须带数据库名或确保当前库正确
执行
DROP TRIGGER tr_name时，MySQL 默认在当前数据库下查找。如果当前库不是触发器所在库，会报错：
ERROR 1360 (HY000): Trigger does not exist，哪怕它真实存在。
安全做法是显式带上库名：
DROP TRIGGER mydb.tr_user_updated_at。也可以先用
USE mydb切换库，再执行删除。 跨库迁移或运维脚本中，漏写库名是高频故障点 删除前建议加条件检查：
SELECT COUNT(*) FROM information_schema.TRIGGERS WHERE TRIGGER_NAME = 'xxx'触发器删除不释放锁，但重建时若表正被 DML 操作，可能触发元数据锁等待
触发器调试困难，禁止在其中调用存储函数以外的外部逻辑
MySQL 触发器里不能执行
COMMIT、
ROLLBACK、
CALL存储过程（除非该过程是
READS SQL DATA或更严格限制）、也不能用
SELECT ... INTO以外的查询结果集。任何违反都会导致
ERROR 1422 (HY000)。
日志几乎只能靠
INSERT INTO debug_log模拟，且该表必须是 InnoDB，否则可能引发事务不一致。更麻烦的是：触发器报错会导致整个原始语句失败，但错误信息往往只提示“trigger failed”，不指明哪一行出问题。 开发阶段尽量把核心逻辑抽成存储函数，便于单独测试 避免在触发器里做网络请求、文件读写、或调用不确定性的系统函数（如
UUID()在某些版本有并发问题）
NEW和
OLD是只读别名，给它们赋值是合法的（用于修改即将插入/更新的值），但对
OLD赋值在
INSERT中无效 触发器一旦启用，就隐式参与每条匹配 DML 的事务，它的执行路径无法被应用层绕过，也很难做单元测试覆盖——这意味着定义时的每个判断分支、每行赋值，都得当成生产代码一样审慎对待。
