必须用SUPER权限加载audit_log插件，MySQL 8.0.16+需SET PERSIST预设；audit_log_policy等变量启动时只读；server_audit需SYSTEM_VARIABLES_ADMIN权限；审计日志文件需正确配置Linux权限及SELinux上下文。
audit_log 插件加载必须用 SUPER 权限
没有 SUPER 权限，INSTALL PLUGIN audit_log SONAME 'audit_log.so' 会直接报错 ERROR 1227 (42501): Access denied; you need (at least one of) the SUPER privilege(s) for this operation。普通 DBA 账号（哪怕有 ALL PRIVILEGES）也不行，MySQL 审计插件加载属于服务器级操作，绕不开这个硬性限制。
临时方案：用 root@localhost 或已授权 SUPER 的账号执行安装；长期方案：在初始化部署阶段就建好专用管理账号，并显式授予：
GRANT SUPER ON *.* TO 'audit_admin'@'localhost';FLUSH PRIVILEGES;
注意：MySQL 8.0.16+ 不再支持 GRANT SUPER 动态添加，必须用 SET PERSIST 或配置文件预设，否则重启后权限丢失。
audit_log_policy 和 audit_log_file 是只读变量，不能靠 GRANT 控制
像 audit_log_policy、audit_log_file、audit_log_format 这些变量，MySQL 设计为“启动时只读”，SET GLOBAL 修改会报错 Variable 'audit_log_policy' is a read only variable。这意味着你无法通过权限控制来开放“运行时开关审计”的能力——它根本不是权限问题，而是架构限制。
真正能由权限影响的，只有两件事：
- 谁能把
audit_log_policy = ALL写进配置文件并重启 MySQL（这属于运维权限，不是 SQL 权限） - 谁有权限读取审计日志文件本身（比如
/var/log/mysql/audit.log，需操作系统层面mysql用户或adm组权限）
server_audit 插件的权限模型更宽松，但仍有隐性要求
如果你用的是 MariaDB 的 server_audit（常用于 MySQL 社区版替代 audit_log），它的加载不强制 SUPER，但仍有两个隐性门槛：
-
INSTALL PLUGIN server_audit SONAME 'server_audit.so'需要SYSTEM_VARIABLES_ADMIN+SESSION_VARIABLES_ADMIN（MySQL 8.0.16+ 替代了旧 SUPER） - 插件启用后，
server_audit_logging可以SET GLOBAL动态开关，但该变量默认 OFF，且只有拥有SYSTEM_VARIABLES_ADMIN的账号才能改
所以即使换插件，也得提前配好对应权限，不能指望普通应用账号去启停审计。
审计日志文件本身的访问权限常被忽略
插件装好了、策略也开了，但 tail -f /var/log/mysql/audit.log 提示 Permission denied？这不是 MySQL 权限问题，是 Linux 文件权限和 SELinux 上下文没对齐。
必须确保：
- 日志路径父目录（如
/var/log/mysql/）属主属组为mysql:mysql，且至少有drwxr-x--- - MySQL 进程实际运行用户（
ps aux | grep mysqld看 USER 列）能写入该路径 - SELinux 处于 enforcing 模式时，
ls -Z /var/log/mysql/应显示system_u:object_r:mysqld_log_t:s0；否则用semanage fcontext -a -t mysqld_log_t "/var/log/mysql(/.*)?"+restorecon -Rv /var/log/mysql
没做这步，审计日志会静默失败——文件不生成、也不报错，连错误日志里都找不到线索。
