audit_log.so存在且路径正确是加载审计插件的前提，需通过SELECT @@plugin_dir确认目录，再用ls -l检查文件存在性、权限及SELinux/AppArmor限制。
检查 audit_log.so 是否存在且路径正确
MySQL 加载 audit_log 插件失败，第一反应不是配置错了，而是文件压根没放对地方。官方二进制包默认不带这个插件，得自己确认：audit_log.so（Linux）或 audit_log.dll（Windows）是否在 plugin_dir 指向的目录里。
- 查当前插件路径：
SELECT @@plugin_dir;，然后去服务器上用ls -l或dir确认文件是否存在、权限是否可读（尤其注意 SELinux 或 AppArmor 限制） - MySQL 8.0.30+ 默认禁用该插件，即使文件存在也需手动安装；5.7 版本则可能随安装包自带但未启用
- 别直接从其他版本 MySQL 复制
audit_log.so—— ABI 不兼容会导致Plugin 'audit_log' init function returned error
验证 MySQL 版本与 audit_log 插件的对应关系
不是所有 MySQL 版本都支持同名插件，也不是所有发行版都提供相同实现。Oracle 官方版、Percona Server、MariaDB 的审计插件名字、参数、甚至加载方式都不同。
- Oracle MySQL 5.7：插件名是
audit_log，动态库为audit_log.so，支持audit_log_policy等系统变量 - Oracle MySQL 8.0+：插件仍叫
audit_log，但默认不打包，需单独下载 MySQL Enterprise Edition 或使用社区替代方案（如mysql-audit插件） - Percona Server：用的是
audit_log，但底层是libaudit_plugin.so，配置项名略有差异（比如audit_log_format而非audit_log_format） - 执行
SELECT VERSION();和SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%audit%';，看返回空还是状态为DISABLED
加载时提示 “Function not implemented” 或 “Can’t open shared library”
这通常不是配置问题，而是运行时环境缺失依赖或内核/OS 层面不支持。特别是容器环境或最小化安装的 Linux 发行版。
-
audit_log插件在部分新版内核（如 RHEL 8+/AlmaLinux 9）中依赖libaudit.so.1，若系统没装audit-libs包，INSTALL PLUGIN audit_log SONAME 'audit_log.so'就会报Function not implemented - Docker 镜像若基于
alpine，基本不可能跑原生audit_log.so（glibc 依赖冲突），得换debian或centos基础镜像 - 用
ldd /path/to/audit_log.so检查缺失的 so，常见缺libaudit.so.1、libpthread.so.0，补全后再试
audit_log_policy 设为 ALL 后 MySQL 启动失败
设成 ALL 表示记录所有语句（含 SET、BEGIN、USE），看似全面，实则极易触发写盘瓶颈或日志轮转异常，尤其在高并发短连接场景下。
- MySQL 启动时若发现
audit_log_file所在磁盘满、权限不对、父目录不存在，会静默失败并拒绝启动 —— 查错误日志里的Could not open audit log file或Permission denied -
audit_log_policy=ALL+audit_log_format=NEW在 5.7.28+ 有已知 hang 问题，建议降级为LOGINS或QUERIES - 务必确认
audit_log_file路径由 MySQL 进程用户（如mysql）可写，且所在文件系统支持大文件（避免 ext3 下单文件超 2GB）
plugin_dir 和 ldd —— 光盯着 my.cnf 改参数，等于在没地基的地方砌墙。 
