MySQL数据库中如何记录和审计用户的DML操作？-mysql教程-PHP中文网

mysql社区版audit_log插件仅记录dml事件元数据（用户、ip、时间、状态码等），不记录sql原文；需结合general_log、binlog或触发器补足dml语句捕获。

mysql数据库中如何记录和审计用户的dml操作？

MySQL 社区版默认不记录 DML 操作的完整 SQL 文本，audit_log 插件只记事件元数据（用户、IP、时间、状态码），不记 DELETE FROM users WHERE id=1 这类语句本身；想真正捕获 DML 内容，必须用其他手段补足。

audit_log 插件能记录什么、不能记录什么

它能记录连接建立、查询开始/结束、DDL（CREATE TABLE）、DML（INSERT/UPDATE/DELETE）等事件类型，但只存动作标签和上下文，不存 SQL 原文。比如你执行 UPDATE orders SET status='shipped' WHERE id=123，日志里只有 "event":"UPDATE"、"user":"app_user"、"status":0，没有那条 UPDATE 语句。

以下操作也不会被 audit_log 捕获：

mysqldump 导出时的 SELECT（走内部协议）
存储过程内拼接执行的动态 SQL（PREPARE/EXECUTE）
复制线程的 apply 操作（binlog replay）

想拿到真实 DML 语句，优先看 general_log

general_log 是唯一原生支持记录完整 SQL 文本的机制，包括所有连接、查询、DML、DDL，甚至空行或注释都会写入。但它不是审计专用，而是调试日志，开启后 I/O 压力明显，生产环境慎用。

启用方式（需有 SUPER 或 SYSTEM_VARIABLES_ADMIN 权限）：

SET GLOBAL general_log = 'ON';
SET GLOBAL log_output = 'FILE';
SET GLOBAL general_log_file = '/var/log/mysql/general.log';

注意：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

general_log_file 必须是绝对路径，MySQL 进程用户（如 mysql）要有写权限
日志文件不会自动轮转，长期开启会导致磁盘打满；建议搭配 logrotate 或仅短期开启
它记录一切，包括健康检查语句（如 SELECT 1），需后期过滤

二进制日志（binlog）可回溯 DML 变更，但需解析

binlog 记录所有造成数据变更的语句（INSERT/UPDATE/DELETE），格式为 STATEMENT 或 ROW。前者存原始 SQL，后者存变更前后的行数据，不直接存语句文本。

要提取 DML 内容：

设 binlog_format = STATEMENT（不推荐，有函数/临时表兼容性问题）
或用 mysqlbinlog --base64-output=decode-rows -v 解析 ROW 格式，从中还原操作意图（例如从 UPDATE event 的 @1=100,@2='new' 推断出更新了哪些字段）
注意：binlog 不记录 SELECT、SHOW、登录行为，也不含执行用户信息——需结合 init_connect 日志补全

触发器方案适合关键表，但有硬伤

对单张敏感表（如 users）建 BEFORE INSERT/UPDATE/DELETE 触发器，把旧值、新值、操作人写进审计表，粒度最细。

示例片段：

CREATE TRIGGER user_audit_trigger 
AFTER UPDATE ON users 
FOR EACH ROW 
INSERT INTO user_audit (user, action, old_data, new_data, change_time) 
VALUES (USER(), 'UPDATE', JSON_OBJECT('id', OLD.id, 'email', OLD.email), 
        JSON_OBJECT('id', NEW.id, 'email', NEW.email), NOW());

问题很现实：