mysql触发器中，before/after update可用old.字段名和new.字段名分别获取修改前后的值；before insert仅能用new，before delete仅能用old；after触发器不可修改new，仅适合日志记录等副作用操作。
触发器里怎么拿到被修改的旧值和新值
MySQL 的 BEFORE UPDATE 和 AFTER UPDATE 触发器中，OLD.字段名 指向更新前的值，NEW.字段名 指向更新后的值。BEFORE INSERT 只能用 NEW，BEFORE DELETE 只能用 OLD。别在 AFTER 触发器里改 NEW —— 这会报错 Can't update table 'xxx' in stored function/trigger。
常见错误是误以为 AFTER 触发器能读写当前行数据，其实它只适合记录日志、发通知这类副作用操作。
- 审计字段如
user_id、ip_address需提前存到应用层变量或临时表里，触发器本身拿不到 HTTP 请求头或登录用户信息 - 如果表有
JSON字段且需审计内部键值变化，得用JSON_CONTAINS+JSON_EXTRACT手动比对，不能靠OLD.col != NEW.col简单判断（JSON 字符串顺序不同也会导致不等） -
OLD和NEW对NULL的比较必须用IS NULL或IS NOT NULL，写成OLD.col = NULL永远返回NULL（即 false）
审计日志表结构怎么设计才不拖慢主业务
审计表不是越全越好。字段太多、索引太重，INSERT 日志本身就会成为瓶颈。建议把日志表引擎设为 ARCHIVE（仅支持 INSERT、压缩率高、无索引）或 MyISAM（无事务开销），避免和主表共用 InnoDB 的 redo log 和锁机制。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 必存字段：操作时间（
NOW()）、操作类型（'INSERT'/'UPDATE'/'DELETE'）、主表名、主键值（如OLD.id或NEW.id）、变更字段名、旧值、新值、操作者标识（需应用传入，触发器无法获取） - 避免存整行快照（比如
JSON_OBJECT('name', OLD.name, 'email', OLD.email)）—— 大字段序列化开销大，且难以后续查询 - 不要给审计表加唯一索引或外键；如果需要按用户查日志，可对
operator_id加普通索引，但前提是这个字段真会被高频查询
触发器里怎么安全地记录操作者和客户端信息
MySQL 触发器无法直接访问应用层的用户身份或 IP 地址。常见做法是：应用在执行 DML 前，先用 SET @audit_user_id = 123 和 SET @audit_client_ip = '192.168.1.5' 设置用户变量，触发器内通过 @audit_user_id 读取。注意变量作用域是会话级，必须保证 SET 和 DML 在同一连接中执行。
- 如果用连接池（如 Druid、HikariCP），必须配置
initSql或每次获取连接后显式SET，否则变量可能残留上一个请求的值 - 禁止在触发器里调用
USER()或CURRENT_USER()当操作者 —— 它们返回的是数据库账号，不是业务用户 - 敏感字段（如密码、身份证号）的日志值应主动脱敏：在触发器里用
CONCAT('***', SUBSTR(NEW.id_card, -4))替换，而不是原样插入
为什么不能用 AFTER INSERT 触发器记录自增 ID
因为 AFTER INSERT 触发器里 NEW.id 已是最终值，包括自增生成的 ID。但如果你在 BEFORE INSERT 里试图给 NEW.id 赋值，会覆盖应用意图（比如应用想指定 ID）。真正要注意的是并发场景下 LAST_INSERT_ID() 不可靠 —— 它返回的是当前会话最后一次 INSERT 生成的 ID，多语句事务中容易错乱。
- 正确做法：所有审计日志都用
AFTER触发器，依赖NEW.id（INSERT）或OLD.id（UPDATE/DELETE）作为关联主键 - 如果主表用复合主键，触发器里必须列出全部字段，比如
OLD.order_id, OLD.item_seq，漏一个就丢失上下文 - 触发器中禁止调用存储函数或复杂子查询，尤其不能查同库其他业务表 —— 容易引发死锁或锁等待超时
实际部署时最常被忽略的一点：触发器错误默认静默失败（除非显式 SIGNAL SQLSTATE），而日志缺失往往要等出问题后回溯才发现。上线前务必用 SELECT * FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'your_db' 校验触发器是否存在且定义正确。
