MySQL触发器必须指定BEFORE/AFTER和单一事件类型（INSERT/UPDATE/DELETE），仅作用于单表；NEW/OLD依事件可用且不可混淆；禁用SBR不安全函数及副作用操作；无调试能力，需严格测试。
触发器定义必须指定 AFTER 或 BEFORE 和事件类型
MySQL 触发器不能脱离执行时机和操作类型独立存在。必须明确是 BEFORE INSERT、AFTER UPDATE 或 BEFORE DELETE 三者之一，且只能作用于单表。常见错误是漏写 AFTER/BEFORE，导致语法报错 ERROR 1064；或试图在同一个触发器里响应多个事件（比如 INSERT OR UPDATE），这是不被支持的。
实操建议：
- 一个触发器只绑定一种事件（
INSERT/UPDATE/DELETE）和一种时机（BEFORE/AFTER） - 若需多事件响应，必须创建多个触发器，命名时带上事件标识便于管理，例如
trg_user_insert_audit、trg_user_update_audit -
BEFORE触发器可修改NEW行值（如自动填充created_at），AFTER则不能改，但能安全引用NEW.id做关联插入
NEW 和 OLD 只在对应事件中可用，且不可混淆
在 INSERT 触发器中，只有 NEW 可用，代表即将插入的行；DELETE 中只有 OLD，代表将被删除的行；UPDATE 中两者都可用，NEW 是新值，OLD 是旧值。误用（比如在 INSERT 里读 OLD.name）会直接报错 ERROR 1327（Undeclared variable）。
实操建议：
- 写触发器前先确认事件类型，再决定访问
NEW还是OLD - 对
UPDATE，常用IF NEW.status != OLD.status THEN ... END IF;做变更检测，避免无意义逻辑执行 - 注意
NEW在BEFORE INSERT中可赋值，在AFTER INSERT中只读；同理OLD在BEFORE DELETE中只读
触发器中不能调用含副作用的函数，比如 UUID()、NOW() 要谨慎
MySQL 允许在触发器中用 NOW()、UUID() 等函数，但它们在语句级复制（SBR）模式下可能导致主从不一致——因为从库重放时时间/UUID 不同步。虽然 5.7+ 默认用 ROW 格式，但若 DBA 切回 SBR，这类触发器就会出问题。
实操建议：
- 优先用
CURRENT_TIMESTAMP（作为列默认值）替代触发器里写NOW() - 需要唯一 ID 时，用
auto_increment主键或UUID_SHORT()（它基于服务器ID+时间，可重复性低且 SBR 安全） - 绝对避免在触发器中调用
SLEEP()、发起外部 HTTP 请求、写文件等操作——MySQL 不允许
触发器调试困难，上线前必须用 SELECT 模拟 + 错误日志验证
MySQL 不提供触发器单步调试能力，也没有 PRINT 或 RAISE（直到 8.0.16+ 才有 SIGNAL）。一旦触发器内部出错（如除零、字段不存在），整个 DML 语句会失败并回滚，但错误信息往往只显示“Trigger xxx has failed”，不指明哪一行。
实操建议：
- 写完触发器后，先手动执行一遍其中的 SQL 片段（把
NEW.xxx换成真实值），确认语法和逻辑正确 - 在测试库开启
general_log = ON，观察实际执行的语句流；或查error_log看是否有TRIGGER相关警告 - 涉及复杂逻辑时，在触发器开头加
INSERT INTO debug_log VALUES (NOW(), 'trg_foo_start');（需提前建表），但上线前务必删掉——否则影响性能且暴露敏感路径
触发器真正难的不是写，而是它隐式运行、无法单独测试、出错时没有上下文。线上环境只要有一个字段名拼错或条件漏判，就可能卡住整张表的写入。
