如何在MySQL 5.7中开启审计日志监控特定用户的非法操作？-mysql教程-PHP中文网

mysql 5.7社区版不支持原生audit_log插件，需用mariadb的server_audit.so替代；它支持用户过滤（incl/excl）、记录事件类型/用户/时间/库表/影响行数，但不记录sql文本，权限操作需显式启用query_dcl，完整审计须结合binlog_rows_query_log_events=on解析原始语句。

如何在mysql 5.7中开启审计日志监控特定用户的非法操作？

MySQL 5.7 社区版根本没有原生 audit_log 插件

直接执行 INSTALL PLUGIN audit_log SONAME 'audit_log.so' 会报错 Plugin 'audit_log' is not loaded——这不是配置问题，是版本不支持。MySQL 5.7 社区版（包括最新 5.7.34）压根不带 audit_log.so，只有企业版才有。你查 SHOW PLUGINS LIKE 'audit_log' 肯定为空，硬装无效。

别被网上“MySQL 5.7 开启 audit_log”的教程误导，那些要么是企业版场景，要么混淆了 MariaDB 的 server_audit 插件。社区版唯一可行路径是引入第三方审计插件。

用 MariaDB 的 server_audit.so 替代，但不能按用户白名单过滤

server_audit.so 是目前最稳定、兼容 MySQL 5.7 的开源审计方案，但它不支持 audit_log_users 这类白名单参数。所谓“监控特定用户”，只能靠两个方式实现：

server_audit_incl_users：只记录指定用户（如 app_admin,etl_job），但注意：它对 CONNECT 事件无效，所有连接都会被记，只是后续查询/表操作才按名单过滤
server_audit_excl_users：排除监控账号（如 monitor,backup），减少噪音，格式必须是逗号分隔、无空格

配置示例（写入 my.cnf 的 [mysqld] 段）：

server_audit=FORCE_PLUS_PERMANENT
server_audit_logging=ON
server_audit_events=CONNECT,QUERY,QUERY_DML,QUERY_DDL
server_audit_incl_users=app_admin,etl_job
server_audit_file_path=/var/log/mysql/server_audit.log

重启后生效，UNINSTALL PLUGIN server_audit 会被拒绝，确保插件不被误删。

日志里看不到 SQL 语句体，别指望 grep "DELETE FROM"

server_audit.so 默认只记录事件类型、用户、主机、时间戳、数据库名、表名、影响行数，**不记录原始 SQL 文本**。你不会在日志里看到 DELETE FROM users WHERE id=123，只会看到 QUERY_DML + users + 1 row affected。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

想追溯具体操作内容，必须搭配：

general_log=ON（性能损耗大，仅临时开启）
或启用 binlog_format=ROW + binlog_rows_query_log_events=ON，再用 mysqlbinlog --base64-output=DECODE-ROWS 解析，其中能还原出 USER 和原始 SQL

单独靠 server_audit 日志，只能确认“谁在什么时间执行了 DML”，无法知道“执行了哪条语句”。

权限修改（GRANT/REVOKE）默认不记录，需显式启用

server_audit_events 默认不含 QUERY_DCL（Data Control Language），所以 GRANT、REVOKE 类操作不会落日志。必须手动加上：

server_audit_events=CONNECT,QUERY,QUERY_DML,QUERY_DDL,QUERY_DCL

否则即使你设了 server_audit_incl_users=app_admin，app_admin 执行的 GRANT ALL ON *.* TO 'hacker'@'%' 也完全静默。另外注意：QUERY_DCL 记录的是语句类型，依然不包含 SQL 文本本身。

真正需要锁定“谁改了权限”，还得依赖 performance_schema.events_statements_history_long 表实时抓取（需提前开启收集器），或解析 binlog（但 binlog 里没有执行者上下文）。

audit_log 或 server_audit 都不是银弹——它们只做事件登记，不存语句体；想追溯到行级变更，binlog + rows_query_log_events 才是不可绕过的环节。漏掉这个组合，等于没装审计。