MySQL不支持列级变更历史功能，需用BEFORE UPDATE触发器配合OLD/NEW显式比对实现；或解析ROW格式binlog，但无操作人信息且有延迟。
MySQL 没有内置列级变更历史功能
直接回答：MySQL 本身不保存任何列的修改记录，binlog 只记录语句或行变更（取决于 binlog_format），但不带“修改前/后值对比”和“由谁改”的上下文；information_schema 和 performance_schema 也不提供列级 DML 审计能力。必须靠人工设计日志表 + 触发器实现。
用 BEFORE UPDATE 触发器捕获列值变化
关键点在于：不能只记录新值，要显式比对旧值和新值，否则日志会爆炸式冗余（比如某列没变也记一条）。触发器里用 OLD.col_name 和 NEW.col_name 判断是否真正变更：
CREATE TRIGGER tr_user_email_update
BEFORE UPDATE ON users
FOR EACH ROW
BEGIN
IF OLD.email != NEW.email THEN
INSERT INTO user_audit_log (table_name, record_id, column_name, old_value, new_value, updated_at, updated_by)
VALUES ('users', OLD.id, 'email', OLD.email, NEW.email, NOW(), COALESCE(@current_user, USER()));
END IF;
END;
-
BEFORE UPDATE是必须的——只有这时OLD和NEW都可用，且可在语句执行前拦截或补充逻辑 - 务必加
IF判断，否则每条UPDATE users SET name='x' WHERE id=1都会触发所有列的日志插入，哪怕email根本没动 -
@current_user是应用层需提前设置的会话变量（如SET @current_user = 'api-service'），MySQL 原生USER()返回的是连接账户，不是业务操作人
触发器无法自动适配新增列或动态列名
一旦表结构变更（比如加了 phone 列），你得手动扩写触发器逻辑——没有“监听所有列”的语法糖。常见错误是写成：
-- ❌ 错误：试图用通配符或动态列名（MySQL 不支持） IF OLD.* != NEW.* THEN ...
正确做法是显式列出需要审计的列：
- 按业务敏感度选列，不是全表每列都记（比如
created_at、status可能比updated_at更值得审计） - 把触发器逻辑封装成模板，配合
INFORMATION_SCHEMA.COLUMNS查询生成 SQL 脚本（适合批量建触发器，但上线前仍需人工 review） - 避免在触发器里做复杂计算或调用函数（如
UUID()、子查询），会影响主 DML 性能，尤其高并发更新场景
替代方案：用 binlog + 解析工具做轻量级变更捕获
如果只是想“知道某列什么时候被改过”，又不想维护触发器，可启用 ROW 格式 binlog 并用 mysqlbinlog 或 Maxwell/Debezium 解析：
- 确认
binlog_format = ROW且binlog_row_image = FULL（否则可能只记变更列，但不带旧值） -
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | grep -A5 "users"可粗略定位，但无法直接过滤“email 列变更” - 真正实用需写解析逻辑（如 Python +
mysql-replication库），提取rows_event中的before_values和after_values字典再比对字段 - 优势：零侵入原表结构；劣势：延迟高、无操作人信息、需额外服务消费 binlog
触发器方案最直接，但每增一个审计列就得改一次触发器；binlog 方案灵活，但工程成本翻倍。选哪个，取决于你能不能接受“改个字段就要改触发器”这件事。
