MySQL触发器必须指定BEFORE/AFTER时机和INSERT/UPDATE/DELETE事件，主体用BEGIN...END包裹且需改分隔符；不支持ALTER，修改须先DROP再CREATE；命名全局唯一，删除需显式指定库名；禁止执行COMMIT、ROLLBACK及非安全操作。

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 中无效