MySQL 8.0+社区版默认不支持Oracle官方audit_log插件，需改用MariaDB的server_audit插件；其支持灵活事件过滤、用户排除和文件输出，配置更实用且开箱即用。
MySQL 8.0+ 如何启用 audit_log 插件
MySQL 自带的 audit_log 插件（由 Oracle 提供）仅在企业版中默认可用，社区版需手动安装且依赖特定编译版本。官方二进制包的社区版通常不包含该插件文件，直接执行 INSTALL PLUGIN audit_log SONAME 'audit_log.so' 会报错 Plugin 'audit_log' is not loaded。
- 社区版用户实际能用的是 MariaDB 的
server_audit插件（兼容 MySQL 协议），或 Percona Server 的audit_log实现 - 若坚持用 Oracle 官方插件，必须确认你的 MySQL 是企业版，或从官网下载含插件的 tar.gz 包（非 yum/apt 安装源）
- 插件文件路径一般为
lib/plugin/audit_log.so（Linux）或lib/plugin/audit_log.dll（Windows），加载前先用SELECT PLUGIN_LIBRARY FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'audit_log';检查是否已注册
audit_log 能记录什么、不能记录什么
它只记录连接建立、断开、查询语句执行（QUERY 类型事件），但不记录查询结果、不解析 SQL 内容、不审计 DML 修改的数据行。比如 UPDATE users SET name='x' WHERE id=1 会被记下，但不会记录旧值/新值；SELECT * FROM salaries 会被记，但返回了哪些行完全不体现。
- 默认只记录
CONNECT、QUERY、QUIT三类事件，需通过audit_log_events变量追加，如设为'CONNECT,QUERY,TABLE,QUERY_DCL'才能捕获GRANT/REVOKE - 不支持按用户、数据库、IP 过滤日志，所有匹配事件全量输出，日志体积增长快，容易撑爆磁盘
- 日志格式固定为 JSON 或 XML，无法自定义字段（比如加 trace_id、应用名），解析依赖外部工具
audit_log_output=file 时的关键配置陷阱
写入文件最常用，但几个参数稍不注意就会导致日志“消失”或“卡死”：
-
audit_log_file必须是 MySQL 进程有写权限的路径，且目录存在；若设为/var/log/mysql/audit.log，但/var/log/mysql不存在或属主不是mysql用户，插件加载成功但日志完全不写入 -
audit_log_buffer_size默认 1MB，高并发下缓冲区满会导致阻塞连接（不是丢日志！），现象是客户端 hang 住几秒后才返回，务必根据 QPS 调大（如 4–8MB） -
audit_log_policy设为ALL会记录所有事件（含内部系统查询），极易打爆 IO；生产环境建议用LOGINS（只记连接）或QUERIES（只记查询），避免全量 - 文件轮转靠外部 logrotate，MySQL 不自动切分；若用
audit_log_rotate_on_size，必须配合audit_log_rotations，否则旧文件不清理
替代方案：用 mysql.server_audit 更现实
MariaDB 的 server_audit 插件可直接用于 MySQL 5.7+/8.0（经验证），社区版开箱即用，配置更灵活：
- 支持
server_audit_logging=ON+server_audit_output_type=file快速启用 - 可通过
server_audit_events精确控制类型（如connect,query,table） - 支持
server_audit_excl_users排除监控账号（如monitor、health_check），减少噪音 - 日志行尾带时间戳和线程 ID，比 Oracle 版本更容易做实时流式分析
审计本身不解决权限滥用，只提供事后追溯依据。真正卡住风险的，是 GRANT 权限的最小化、定期回收，以及应用连接池复用账号带来的操作归属模糊——这些，日志里都看不出是谁点的那条 SQL。
