MySQL 默认不开启审计日志功能，需借助企业版的 Audit Log Plugin 或第三方插件（如 MariaDB 的 audit plugin、Percona 的 audit log plugin）来实现操作行为记录。社区版 MySQL 本身不提供原生审计日志，但可通过通用查询日志（General Query Log）或二进制日志（Binary Log）间接辅助审计，不过二者各有局限。
启用 MySQL 企业版审计日志（Audit Log Plugin）
这是最规范的审计方式，适用于已购买 MySQL Enterprise Edition 的用户：
确认插件可用：SHOW PLUGINS;查看
audit_log是否处于
ACTIVE状态 若未加载，执行：
INSTALL PLUGIN audit_log SONAME 'audit_log.so';（Linux）或
audit_log.dll（Windows） 常用配置项（写入
my.cnf或动态设置）：
audit_log=FORCE_PLUS_PERMANENT（强制启用且禁止卸载）
audit_log_format=JSON（推荐，结构清晰易解析）
audit_log_policy=ALL（记录所有连接、查询、管理命令；也可设为
LOGINS或
QUERIES）
audit_log_file=/var/lib/mysql/audit.log（指定路径，确保 MySQL 进程有写权限） 重启 MySQL 或执行
SET PERSIST audit_log_policy = 'ALL';生效
用通用查询日志（General Log）临时审计
适用于调试或短期排查，不建议长期开启（性能损耗大、日志体积爆炸）：
启用方式：SET GLOBAL general_log = ON;，并指定输出目标：
SET GLOBAL log_output = 'FILE';（或
'TABLE'写入
mysql.general_log表） 日志包含客户端 IP、用户名、执行时间、完整 SQL 语句，但无返回结果、无权限判断上下文 注意：敏感操作（如
DROP TABLE、
DELETE FROM users）会明文记录，需做好日志文件访问控制 定期清理：
SET GLOBAL general_log_file = '/tmp/general_new.log';可轮转，或清空表日志：
TRUNCATE TABLE mysql.general_log;
结合 Binary Log 分析高危变更操作
Binlog 本身用于复制和恢复，但也能反向追踪 DDL/DML 变更来源：
确保binlog_format = ROW（推荐）或
MIXED，才能看到具体修改的行级数据 用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001解析日志，可识别谁（通过
SET @@session.pseudo_thread_id关联 event）、何时、执行了什么变更 缺点：不记录 SELECT、不记录登录失败、不含客户端 IP（除非启用
log_bin_trust_function_creators配合自定义日志表） 可搭配触发器+日志表做补充：例如在关键表上建 AFTER UPDATE 触发器，将操作人、时间、旧值新值写入审计表
实用建议与注意事项
真实环境中审计不是“开个日志就完事”，需兼顾安全性、可维护性与合规要求：
审计日志必须独立存储，权限严格限制（仅 DBA 和安全团队可读），避免被篡改或删除 定期归档与压缩（如用logrotate），设置保留周期（如 180 天），满足等保或 GDPR 要求 避免在生产库直接开启全量审计；可按需启用策略，例如只对
admin账户或
payment库开启细粒度记录 考虑使用开源审计代理（如 ProxySQL + 自定义日志模块）或数据库防火墙（如 MaxScale、Aliyun DAS）实现旁路审计，降低主库压力
