MySQL 默认不支持原生审计日志，企业版需启用 Audit Log Plugin，社区版可借助通用查询日志或二进制日志间接审计，但各有局限；推荐结合插件配置、日志隔离、定期归档与旁路方案实现合规审计。
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）实现旁路审计，降低主库压力
