AFTER UPDATE触发器能获取OLD值，它代表变更前整行且只读；常见误解源于表名错误、字段类型不匹配或误在BEFORE中修改OLD导致逻辑异常。
为什么 AFTER UPDATE 触发器拿不到 OLD 值？
先说一个核心判断：答案是肯定的，能拿到。这其实是一个常见的误区。AFTER UPDATE 触发器完全支持访问 OLD 和 NEW 这两条伪记录，这是 MySQL 的标准行为，毋庸置疑。那么，为什么会有“拿不到”的错觉呢？问题往往出在细节上：要么是触发器被错误地绑定到了其他表上，要么是在 BEFORE UPDATE 触发器中试图对只读的 OLD 值进行操作，干扰了后续的逻辑判断。但无论如何，在 AFTER 阶段，OLD 值始终是完整且只读的。
如何用 AFTER UPDATE 触发器安全记录旧值
所以，关键不在于“能不能”，而在于“怎么记”。一个健壮的日志方案，目标应该是确保记录不漏、不错，同时不影响主业务的性能。这里面的门道，主要集中在日志表的设计和触发器内部的字段处理策略上。
- 日志表结构要周全：除了自增的
log_id，务必包含table_name（原表名）、row_id（原表主键值）、old_data（建议用 JSON 格式存储所有OLD字段）、updated_at以及可选的updated_by（注意，MySQL 触发器不自动提供当前用户，需通过应用层传入）。 - 保持触发器轻量：尽量避免在触发器内部调用复杂函数或执行额外的查询，尤其是跨库操作，否则很容易拖慢主更新事务。
- 字段拼接要谨慎：别再用
CONCAT粗暴地拼接所有字段了，数据类型不一致很容易导致错误或信息丢失。对于 MySQL 5.7 及以上版本，使用JSON_OBJECT()函数来构建old_data是更可靠的选择。 - 处理复合主键：如果原表的主键由多个字段组成，那么
row_id字段建议使用VARCHAR(512)来存储 JSON 编码后的键值对，以确保唯一性标识的完整性。
来看一个具体的触发器示例：
INSERT INTO user_log (table_name, row_id, old_data, updated_at)
VALUES ('user', OLD.id, JSON_OBJECT('name', OLD.name, 'email', OLD.email, 'status', OLD.status), NOW());
OLD 值在 AFTER UPDATE 中被意外清空或为 NULL？
遇到这种情况，先别急着怀疑 MySQL。十有八九，问题出在触发器本身的定义或周边逻辑上。市场上不乏这样的案例，通常可以沿着以下几个方向排查：
- 表名绑定错误：检查触发器是否确实绑定在了正确的表上。一个字母之差，就可能让
OLD指向完全不同的上下文。 - BEFORE 触发器的干扰：虽然在
BEFORE UPDATE触发器中直接对OLD赋值在语法上不被允许（MySQL 会静默忽略），但这类错误的尝试可能会破坏后续的业务逻辑流。 - 字段类型不匹配：如果原表字段是
TEXT或BLOB - 误判 NULL 值：触发器中如果使用了
IF OLD.col IS NULL这样的判断，需要先确认该字段是否本身就允许为 NULL。它可能只是正常地为空，而非出现了异常。
性能与事务一致性要注意什么
使用触发器记录日志，有一个至关重要的特性：AFTER UPDATE 触发器的操作与主 DML 语句处于同一个事务中。这意味着日志的写入会随着主操作的提交而提交，回滚而回滚，从而保证了数据的一致性。但凡事都有代价，这个机制的代价就是可能延长锁的持有时间。
- 确保事务原子性：日志表必须与原表在同一个数据库内，并且使用相同的事务型存储引擎（如 InnoDB）。否则，无法保证操作的原子性。
- 索引设计要克制：切忌给日志表添加过多索引，更不要在
old_data这类 JSON 字段上建立全文索引，否则写入性能会急剧下降。 - 警惕热点瓶颈：在高并发更新场景下，日志表的自增主键可能成为争抢的热点。可以考虑按时间分表，或者使用带前缀的 UUID 来分散写入压力。
- 评估替代方案：如果业务可以接受最终一致性，那么利用 MySQL 的
BINLOG配合解析工具（如 Maxwell、Canal）来实现变更捕获，往往是比触发器更轻量、解耦的方案。
最后，需要特别警惕一个“坑”：绝对不要在触发器内部使用 SELECT ... FOR UPDATE 或任何其他显式加锁的语句。MySQL 会直接抛出 ERROR 1442 (HY000): Can‘t update table in stored function/trigger 错误，导致操作失败。这才是关键所在。
