必须用after触发器做审计记录，因为before中old（insert）和new（delete）不可用，且事务回滚会导致日志与数据不一致；after中new（insert/update）、old（update/delete）均稳定可用且值真实。
必须用 AFTER 触发器，NEW 和 OLD 才能稳定可用；BEFORE 里 OLD 在 INSERT 中不可用、NEW 在 DELETE 中不可用，强行访问会报 Unknown column 'OLD.id' in 'field list'。
为什么不能在 BEFORE 触发器里做审计记录
BEFORE INSERT 没有 OLD，BEFORE DELETE 没有 NEW，只有 UPDATE 同时有两者——但审计要覆盖全部操作类型，不能只靠一种场景撑住。更关键的是：BEFORE 阶段变更尚未落地，事务若回滚，日志却已写入，导致日志与实际数据不一致。
-
AFTER INSERT：NEW已完全确定（包括自增主键值），可安全读取 -
AFTER UPDATE：OLD和NEW均完整可用，且值真实反映已提交的变更 -
AFTER DELETE：OLD是唯一能拿到被删行数据的时机
NEW 和 OLD 在不同操作中的可用性边界
误用 NEW/OLD 是触发器报错最常见原因。它们不是变量，而是上下文快照，生命周期严格绑定于触发时机。
-
INSERT：仅NEW可用；OLD访问直接报错 -
UPDATE：OLD和NEW都可用；但OLD.col = NEW.col时字段未变更，不应记录 -
DELETE：仅OLD可用；NEW访问直接报错 - 所有
AFTER触发器中，NEW不可被赋值（如SET NEW.name = 'x'）——会报Can't update NEW row in after trigger
如何安全提取和拼接 NEW/OLD 字段值
直接 CONCAT(OLD.name, NEW.name) 很危险：任一为 NULL，整个结果就是 NULL；大字段（如 TEXT、JSON）可能超 max_allowed_packet 或触发截断警告。
- 对
NULL显式处理：IFNULL(OLD.email, 'NULL')，别依赖隐式转换 - 避免全字段无脑拼接；
UPDATE触发器里必须加判断：IF OLD.status != NEW.status THEN ... - 存变更内容优先用
JSON_OBJECT()（MySQL 5.7+）：JSON_OBJECT('status', OLD.status, 'email', OLD.email)，比字符串拼接健壮 - 若用
LONGTEXT存原始值，确保日志表该字段长度足够，且客户端连接的max_allowed_packet≥ 预期最大日志行
获取操作人信息不能只靠 USER()
USER() 返回 'app_user@10.20.30.40'，但生产环境常经代理或连接池，IP 不可靠；账号复用时更无法区分具体操作人。
- 最稳妥方式：应用层执行业务 SQL 前先
SET @audit_user = 'alice'，触发器中读@audit_user - 次选方案：
SUBSTRING_INDEX(USER(), '@', 1)截取用户名，但需 DBA 约定账号命名规范 - 绝对避免：
CURRENT_USER()—— 它返回权限校验后的账号，常为'app_user@%'，丢失主机/用户粒度 - 时间必须用
NOW(3)，不用CURRENT_TIMESTAMP—— 后者在某些复制拓扑下会取从库系统时间
真正难的不是写出第一个触发器，而是让所有 AFTER 触发器在高并发批量更新、含 TEXT 字段的 UPDATE、以及连接池环境下，始终不丢日志、不拖慢主流程、不因某个字段长度突变而静默失败。这些细节藏在每一条 IF 判断和每一次 IFNULL 调用里。
