能，但需手动编写逻辑：在AFTER触发器中用USER()和NOW(3)记录操作人与时间，审计表须独立设计、避免外键与冗余索引，并注意MySQL 5.7/8.0在JSON支持与sql_log_bin上的差异。
触发器能自动记录谁在什么时候改了哪条数据吗
能，但必须手动写逻辑，MySQL 触发器本身不提供“审计”功能，只提供执行时机（BEFORE 或 AFTER）和上下文（OLD、NEW）。你得自己决定记什么、存到哪、怎么防冲突。
常见错误现象：INSERT 时想读 OLD.id 报错；UPDATE 里漏判 OLD.col != NEW.col，导致无变更也写日志；没加 IF NOT (OLD.col NEW.col) 就直接记录，日志爆炸。
- 只在
AFTER INSERT/AFTER UPDATE/AFTER DELETE中写审计日志，避免事务回滚后日志残留 - 用
USER()获取当前连接用户（不是应用层传的账号），注意它返回'user@host'格式，可能需SUBSTRING_INDEX(USER(), '@', 1)截取 - 记录时间统一用
NOW(3)，别用SYS_DATE()或CURRENT_TIMESTAMP（语义模糊，部分版本行为不一致） - 敏感字段（如密码、手机号）必须显式排除，触发器里不会自动脱敏
审计表结构怎么设计才不容易翻车
核心原则：审计表不能和原表强耦合，否则改原表结构就崩。最容易踩的坑是直接用 CREATE TABLE audit_log LIKE origin_table —— 这会把主键、索引、默认值全抄过来，而审计表根本不需要这些。
正确做法是手建极简结构，例如：
CREATE TABLE user_audit (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
table_name VARCHAR(64) NOT NULL,
op_type ENUM('INSERT','UPDATE','DELETE') NOT NULL,
pk_value VARCHAR(255) NOT NULL COMMENT '主键值，转字符串存，兼容复合主键',
changed_fields JSON COMMENT '仅记录变更字段，如 {"email": ["old@x.com", "new@x.com"]}',
operator VARCHAR(128) NOT NULL,
created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3)
);
-
pk_value必须是VARCHAR，不能照搬原表主键类型——万一原表主键是UUID或复合键，数值型字段撑不住 - 别给审计表加外键，否则删原表时会失败；也别加索引到
changed_fields（JSON 字段无法高效索引变更内容） - 如果业务要求查“某人改过哪些订单”，就在
operator和table_name上建联合索引，别一上来就全字段索引
触发器里调用 INSERT INTO audit_log 为什么总报错
最常见原因是触发器里试图修改当前正在被触发的表（比如 user 表的 AFTER UPDATE 触发器再去 UPDATE user），MySQL 直接报 Can't update table 'user' in stored function/trigger。
另一个高频问题是事务隔离：触发器属于当前事务，如果主 SQL 回滚，审计日志也会消失——这违反审计“不可抵赖”原则。
- 审计日志必须写入**独立表**，且该表引擎用
MyISAM或ARCHIVE（不支持事务），才能保证日志不随主事务回滚 - 不要在触发器里做耗时操作：比如调用
SELECT查其他大表、拼接长字符串、解析 JSON——会拖慢所有 DML 操作 - 避免在
BEFORE触发器里写审计日志：此时NEW.id可能还没生成（自增场景），OLD在INSERT里又为空，字段来源不可靠
MySQL 5.7 和 8.0 在审计触发器上有什么关键差异
8.0 的 JSON_OBJECT() 和 JSON_CONTAINS() 让字段变更检测更干净，但 5.7 只能靠一堆 IF 判断，代码冗长易错。真正要命的是权限模型变化。
MySQL 8.0 默认启用 sql_log_bin=OFF 在触发器内，意味着写审计表的操作不会被复制到从库——如果你依赖从库查审计日志，会发现从库审计表永远为空。
- 8.0 下必须显式加
SET sql_log_bin = ON;到触发器开头（注意：仅对当前会话有效，且需SYSTEM_VARIABLES_ADMIN权限） - 5.7 不支持
JSON_INSERT()，拼changed_fields得用字符串拼接 +CONCAT()，容易注入或格式错乱，务必用REPLACE()清掉换行和双引号 - 两个版本都不支持在触发器里调用存储过程返回结果集，所以别想封装通用审计逻辑——每个表的触发器都得单独写
最麻烦的其实是并发：多个线程同时更新同一行，触发器写的审计日志顺序可能和实际执行顺序不一致，连 created_at 都救不了——这事没法靠 MySQL 自身解决，得在应用层加追踪 ID 或用外部消息队列兜底。
