MySQL 8.0 启用 audit_log 插件需先 INSTALL PLUGIN 加载，再 SET GLOBAL audit_log_policy = 'ALL' 开启；audit_log_file 和 audit_log_format 必须在 my.cnf 中配置并重启生效，路径需 mysql 用户可写，JSON 格式需 jq 解析，LOGINS 模式可能导致连接阻塞。
MySQL 8.0 自带 audit_log 插件怎么启用
MySQL 8.0+ 内置了 audit_log 插件，不需要额外安装，但默认不激活。它不是靠配置文件开关，而是靠运行时加载 + 显式启用。
- 先确认插件存在：
SHOW PLUGINS;查看audit_log是否在列表中（状态为ACTIVE或DISABLED） - 如果没加载，执行：
INSTALL PLUGIN audit_log SONAME 'audit_log.so';（Linux）或'audit_log.dll'（Windows） - 加载后必须设全局变量才生效：
SET GLOBAL audit_log_policy = 'ALL';（可选值：ALL、LOGINS、QUERIES） - 日志默认写到
datadir下的audit.log，路径不能直接改——得靠audit_log_file变量，但该变量只读，需在启动前通过配置文件指定
audit_log_file 路径怎么安全指定
想把审计日志放到 /var/log/mysql/audit.log？别直接改 my.cnf 就完事。MySQL 启动时会校验路径权限，且插件对目录有硬性要求。
-
audit_log_file必须在 MySQL 启动前写入配置文件（如my.cnf的[mysqld]段），运行时SET GLOBAL不生效 - MySQL 进程用户（通常是
mysql）必须对目标目录有wr权限，且父目录不能是 root-only（比如/var/log默认不允许 mysql 写） - 常见错误：
Could not open audit log file—— 大概率是权限或 SELinux 拦截，先试chown mysql:mysql /var/log/mysql，再检查ls -Z /var/log/mysql - 路径中不能含变量（如
$DATADIR），必须是绝对路径
audit_log_format = JSON 为什么日志看不懂
设成 JSON 格式后，日志里一堆转义和嵌套字段，不是 bug，是设计如此。MySQL 审计日志的 JSON 是单行、无缩进、字段固定，适合机器解析，不适合人眼扫读。
- 可用
jq快速格式化：tail -f /var/log/mysql/audit.log | jq '.'（前提是每行一个合法 JSON 对象） - 注意
audit_log_format是只读变量，只能在配置文件里设，重启生效；XML格式更易读但体积大、解析慢，企业环境基本没人用 - 关键字段如
name（操作类型）、status（0=成功）、query（SQL 内容）都存在，但query在 DDL 或敏感语句中可能被截断或脱敏（取决于audit_log_include_accounts等策略） - 别指望它记录参数化查询的绑定值——
audit_log只记录客户端发来的原始字符串
audit_log_policy = LOGINS 导致登录失败率飙升
设成 LOGINS 后发现应用连不上，报 Access denied 或连接超时，不是认证逻辑变了，而是日志写入阻塞了连接建立流程。
-
LOGINS模式会在每次连接握手完成、权限检查后立即写日志，若磁盘慢或日志目录满，MySQL 会卡住整个连接线程，表现就是连接变慢甚至超时 - 生产环境慎用
LOGINS，尤其高并发短连接场景（如 PHP-FPM、云函数类调用）；ALL虽然日志多，但异步刷盘更稳 - 监控要点：看
SHOW STATUS LIKE 'Audit_log%';中的Audit_log_write_waits，非零说明写日志已开始拖慢主线程 - 真正要控登录行为，优先考虑
max_connections、host_cache和防火墙层限流，审计日志只是事后追溯手段
审计日志不是开关一开就万事大吉的东西，它和磁盘 I/O、账户权限、SELinux 策略、MySQL 启动顺序全绑在一起。最常出问题的不是配置项写错，而是以为“配完就能用”，忘了验证进程用户能不能写目标路径、忘了重启是否真加载了插件、忘了 JSON 日志得靠外部工具才能看清。
