AFTER UPDATE触发器必须显式比对关键业务字段（如status、email），跳过updated_at等自动字段，用IFNULL处理NULL，禁用全量行比对；OLD/NEW仅在AFTER中安全可读且只读；审计表用JSON存差异、NOW(3)记时、索引精简；操作人需应用层设@_app_user变量兜底。
AFTER UPDATE触发器必须加字段变更判断
不加判断会导致每条UPDATE语句都写日志，哪怕name、email一个字没改，也会生成一条冗余记录——线上单表日均百万级UPDATE时，审计表一天就涨几个G。
正确做法是显式比对关键业务字段，跳过自动更新字段（如updated_at）：
IF OLD.status != NEW.status OR OLD.email != NEW.email THEN- 用
IFNULL()包裹可能为NULL的字段，避免整个条件判NULL导致逻辑失效 - 不要用
OLD.* = NEW.*全量比对——MySQL不支持行级相等语法，会报Unknown column 'OLD.*' in 'field list' - 大字段（如
TEXT、JSON）慎比：长度超max_allowed_packet可能触发截断警告，建议只比ID、状态、金额等确定性字段
OLD和NEW字段只能在AFTER UPDATE里安全读取
AFTER UPDATE是唯一能同时稳定访问OLD和NEW的时机。BEFORE UPDATE虽也能读，但事务未提交，若后续回滚，日志就成了“假变更”；而AFTER阶段数据已落盘或至少在事务内可见，值真实可靠。
常见误用：
- 在
AFTER UPDATE里给NEW.name赋值——报Can't update NEW row in after trigger，AFTER中NEW只读 - 把
OLD.updated_at当成“上次修改时间”——它只是原字段值，未必反映真实历史；真正要记的是本次操作发生时间，得用NOW(3) - 漏写
DELIMITER $$就直接建触发器——MySQL默认分号结束，触发器体内的分号会让语法提前终止，建不成功
审计表结构设计直接影响性能和可查性
审计表不是主表镜像，字段越多、索引越全，触发器执行越慢。线上环境尤其要注意三点：
- 时间字段必须用
NOW(3)，别用CURRENT_TIMESTAMP——后者可能固化在语句开始时刻，和实际执行时间差几十毫秒，排查时序问题会错乱 -
old_data和new_data建议用JSON类型存差异字段，而不是全量快照；字段名统一小写，避免大小写敏感问题 - 只建必要索引：
INDEX idx_table_record (table_name, record_id)够日常定位；别给created_at单独建索引，除非高频按时间范围查全量变更 - 引擎必须是
InnoDB，否则跨引擎事务可能失败；字符集统一utf8mb4，防emoji插入报错
操作人信息不能依赖USER()硬编码
应用用了连接池后，USER()返回的全是中间件账号（比如app@10.0.1.5），丢失真实操作者。必须由应用层在执行DML前显式设置会话变量：
SET @app_user = 'admin@192.168.1.100';
然后在触发器里读：IFNULL(@app_user, USER())。这样既兼容直连场景，又不失真于连接池环境。
容易被忽略的点：
- 会话变量生命周期仅限当前连接，不能跨请求复用；应用每次请求都要重设
- 触发器里不能用
SELECT USER()替代USER()函数——前者走查询流程，开销大且可能被权限限制 - 如果应用没传
@app_user，兜底用USER()加CONNECTION_ID()组合，至少能区分不同连接
最麻烦的其实是复合主键和JSON字段处理——这两处出问题时，错误提示往往不直观，得靠SHOW CREATE TRIGGER反复核对字段映射和NULL容忍逻辑。
