MySQL触发器：BEFORE与AFTER触发时机

理解 BEFORE 与 AFTER：触发时机和核心区别

MySQL 触发器的核心在于执行时机。BEFORE 触发器在数据实际写入存储引擎之前执行，此时可以拦截并修改即将落盘的数据；AFTER 触发器则在数据变更成功写入后执行，主要用于记录日志或触发后续业务逻辑。在伪记录访问方面，BEFORE 阶段允许读取和修改 NEW（INSERT/UPDATE）与 OLD（UPDATE/DELETE）记录，而 AFTER 阶段仅支持读取 NEW 和 OLD，任何对 NEW 字段的赋值操作都会被 MySQL 静默忽略。选择策略非常明确：若需对输入数据进行格式清洗、默认值填充或合法性拦截（如校验金额非负），应选用 BEFORE；若需在数据落盘后同步更新关联表、写入审计流水或发送异步通知，则必须使用 AFTER。理解这一时序差异是避免数据不一致与逻辑冲突的前提。

创建 BEFORE 与 AFTER 触发器：语法与实战场景

创建触发器的标准语法为 CREATE TRIGGER trigger_name {BEFORE|AFTER} {INSERT|UPDATE|DELETE} ON table_name FOR EACH ROW BEGIN ... END;。以用户表为例，BEFORE INSERT 可用于数据规范化：CREATE TRIGGER before_user_insert BEFORE INSERT ON users FOR EACH ROW SET NEW.email = LOWER(NEW.email);，确保邮箱统一小写。AFTER INSERT 则适合记录审计：CREATE TRIGGER after_user_insert AFTER INSERT ON users FOR EACH ROW INSERT INTO user_logs(user_id, action) VALUES (NEW.id, 'CREATE');。对于 UPDATE 操作，BEFORE 可校验 NEW.price > OLD.price 防止恶意改价，AFTER 可同步扣减库存表。DELETE 场景下，BEFORE 常用于软删除拦截或权限校验，AFTER 则用于清理关联缓存或归档历史数据。编写时需严格对应不同 DML 语句下 NEW/OLD 的生命周期。

验证触发器：执行顺序、NEW/OLD 与结果检查

验证触发器需构建可观测的测试链路。首先创建主表 orders 与日志表 order_audit，分别绑定 BEFORE UPDATE 与 AFTER UPDATE 触发器。执行 UPDATE orders SET status = 'PAID' WHERE id = 1; 后，通过 SELECT * FROM orders; 确认状态已变更，再查询 order_audit 表应存在一条记录，其 old_status 为原值，new_status 为 'PAID'。排查时需注意：INSERT 操作仅有 NEW 可用，OLD 为 NULL；DELETE 操作仅有 OLD 可用，NEW 为 NULL；UPDATE 则两者皆可用。若触发器未生效，可通过 SHOW TRIGGERS; 检查是否存在，或使用 SET GLOBAL log_bin_trust_function_creators = 1; 排除权限限制。建议在测试环境开启 general_log 或使用 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Debug'; 强制中断以观察执行栈，确保逻辑按预期流转。

常见坑与选择建议：避免触发器失控

触发器滥用极易引发系统失控。首要陷阱是时机选错：在 AFTER 中尝试修改 NEW 字段会导致静默失败，而在 BEFORE 中执行跨表写入可能引发行锁竞争。其次，隐式数据修改会破坏业务层预期，导致 ORM 框架返回的数据与数据库实际状态不一致。事务回滚时，若 AFTER 触发器写入的日志表未在同一事务内，将产生无法追溯的“幽灵数据”。此外，多触发器维护困难，MySQL 8.0 虽支持多触发器但执行顺序依赖创建时间，极易产生隐式依赖。递归触发（如触发器更新本表再次触发自身）会直接抛出 ERROR 1442 堆栈溢出。选型检查清单：1. 是否需拦截或修改数据？选 BEFORE。2. 是否仅做记录或异步联动？选 AFTER。3. 是否涉及跨库/长事务？优先改用应用层事件或消息队列。4. 是否可被业务代码替代？能替代则坚决移除触发器，保持逻辑显式化。