简介MySQL 5.7 社区版安全审计插件是针对Linux 64位系统的专业数据库审计组件面向需要满足安全合规要求或强化数据库监控的DBA、运维人员与安全工程师可完整记录SQL操作、登录与权限变更等行为助力审计追溯与故障排查。压缩包共6个文件、体积约568KB包含插件动态库、Shell辅助脚本及多份说明文档txt文件用于安装配置介绍和组件声明so文件为审计插件本体sh脚本可辅助偏移提取COPYING则保留开源许可信息结构小巧便于快速评估。资源包目前已有1143人学习下载。获取后可直接解压并对照文档部署明确插件安装、启用和日志策略配置的关键路径适合在测试环境先验证再投入生产尤其在MySQL 5.7社区版缺少官方审计功能时可作为轻量、可靠的补充方案。1. audit-plugin-mysql-5.7-1.1.7-921-linux-x86_64.zip 是什么一条能查“谁的 SQL”的审计日志链audit-plugin-mysql-5.7-1.1.7-921-linux-x86_64.zip 这个文件名里每一段都是信息mysql-5.7 表示按 MySQL 5.7 插件 API 编译1.1.7-921 是插件版本与构建号linux-x86_64 决定它只能装到 64 位 Linux 的 mysqld 里。装上它之后谁在什么时间、从哪个客户端 IP、用哪个账号执行了哪条 SQL都会被写进结构化审计日志而不是靠 MySQL 自带的 general log 硬扛。它解决两条刚需合规要求数据库有可追溯的访问记录出事时能快速定位某条高危 SQL 是谁执行的。适合的人很明确正在维护 MySQL 5.7、被等保或内部审计追着走的 DBA 和运维工程师以及要给客户交付“可审计数据库”的部署同学。下面按实际部署顺序写先对版本再安装再验证最后讲坑。2. 安装前先对齐环境版本 ABI、插件目录与四项检查清单2.1 为什么 1.1.7-921 只适配 MySQL 5.7版本号与 ABIMySQL 插件本质是一个编译好的共享库加载后直接跑在 mysqld 进程里。它要调用 MySQL 内部的插件 API而 5.6、5.7、8.0 各版本的插件结构体和函数签名并不一样这就是 ABI应用二进制接口差异。一个按 5.7 头文件编译出来的插件放进 8.0 的 plugin_dir 后 INSTALL PLUGIN 会直接报版本不符运气好点加载成功也会在特定语句执行时出问题属于“黑匣子型”故障。所以第一件事是把版本锁死。1.1.7 是插件自身的版本号921 是这套包的构建号它对应 MySQL 5.7 系列你只需要记住这套 zip 只服务 MySQL 5.7不通用。i386、ARM 或其他 Linux 发行版也不能直接套这个 x86_64 包常见做法是先在一台和线上 OS 一致的测试机上验证再铺开。真要确认构建号对应哪些修复内容去拿到包的发布页看 Release Notes别靠猜。2.2 安装前的四项检查版本、插件目录、存量插件与磁盘我一般不会上来就 unzip先花两分钟跑一组只读检查把环境摸清楚。下面这段就是部署前最常用的检查脚本# 1) 确认 MySQL 主版本必须落在 5.7 mysql -uroot -p -e SELECT VERSION(); # 2) 拿到插件目录后面 .so 就放在这里 mysql -uroot -p -e SHOW VARIABLES LIKE plugin_dir; # 3) 检查是否已有 audit 相关插件避免重复加载 mysql -uroot -p -e SHOW PLUGINS; | grep -i audit # 4) 确认 unzip 可用、数据盘有空间 unzip -v /dev/null 21 echo unzip available df -h /var/lib/mysql逐条说下执行逻辑。第 1 条 SELECT VERSION() 会输出类似 5.7.44-log 的完整版本只要大版本是 5.7 就可以继续。第 2 条 plugin_dir 决定你稍后把 libaudit_plugin.so 复制到哪常见值是 /usr/lib/mysql/plugin 或 /usr/lib64/mysql/plugin不同发行版不一样必须以这行输出为准。第 3 条是防止已经装过别的审计插件同名的 AUDIT 插件只能有一个重复加载会互相干扰。第 4 条看 unzip 命令和磁盘zip 解开一般也就几十 MB重点是审计日志将来落盘的目录要有足够空间。2.3 解压后该看到什么结构、架构与动态库检查检查通过后开始解压并顺手确认 .so 的架构与依赖unzip audit-plugin-mysql-5.7-1.1.7-921-linux-x86_64.zip # 解压后进入目录常见布局是 lib/ 下有核心 .sodocs/ 下有说明文档 ls -lR audit-plugin-mysql-5.7-1.1.7-921-linux-x86_64 # 确认 .so 是 64 位 x86 ELF file audit-plugin-mysql-5.7-1.1.7-921-linux-x86_64/lib/libaudit_plugin.so # 检查动态库依赖是否齐全出现 not found 要先补依赖 ldd audit-plugin-mysql-5.7-1.1.7-921-linux-x86_64/lib/libaudit_plugin.sofile 输出里出现 “ELF 64-bit LSB shared object, x86-64” 就说明架构对得上。ldd 如果出现 libxxx.so not found说明系统缺库最常见的是 libaio 之类的基础依赖补齐后再继续。这一步能挡掉一大半“装完一执行就出问题”的玄学故障。依赖干净了再把它复制进 plugin_dir。3. 把 zip 变成在线插件INSTALL PLUGIN 与 my.cnf 持久化3.1 复制 .so 到 plugin_dir 并确认属主权限明确 .so 路径后用下面命令复制并设置权限PLUGIN_DIR$(mysql -uroot -p -e SHOW VARIABLES LIKE plugin_dir; | awk NR2{print $2}) cp audit-plugin-mysql-5.7-1.1.7-921-linux-x86_64/lib/libaudit_plugin.so $PLUGIN_DIR/ chown mysql:mysql $PLUGIN_DIR/libaudit_plugin.so chmod 755 $PLUGIN_DIR/libaudit_plugin.so ls -l $PLUGIN_DIR/libaudit_plugin.so这段先把 plugin_dir 的值取到变量里避免手抄路径出错。cp 之后必须确认属主是运行 mysqld 的系统用户通常是 mysql否则加载时会出现权限类报错。chmod 755 保证可读可执行。常见的翻车点是复制完忘了 chown插件加载时日志里只留一句含糊的权限错误排查起来很费时间。3.2 INSTALL PLUGIN 注册与重启后的两件套复制到位后进入 MySQL 执行注册-- 注册 AUDIT 插件SONAME 必须和 .so 文件名完全一致 INSTALL PLUGIN AUDIT SONAME libaudit_plugin.so; -- 确认已加载且状态为 ACTIVE SHOW PLUGINS; SELECT PLUGIN_NAME, PLUGIN_STATUS, PLUGIN_VERSION FROM information_schema.plugins WHERE PLUGIN_NAME AUDIT;INSTALL PLUGIN 会在 mysql.plugin 表里写一条记录正常情况下重启后会自动加载这就是它和 LOAD PLUGIN 的区别。但我的习惯是双保险my.cnf 的 [mysqld] 段里同时加上 plugin-load-add并把审计参数也写进去这样即使实例做过迁移、重建配置也跟着走。下面是一个最小持久化配置[mysqld] plugin-load-addAUDITlibaudit_plugin.so audit_json_fileON audit_json_log_file/var/log/mysql-audit/mysql-audit.json audit_record_objectsON参数说明plugin-load-add 是启动时加载插件的兜底写法等号左边 AUDIT 是插件名右边是 .so 文件名audit_json_file 控制是否写 JSON 格式审计日志audit_json_log_file 指定日志绝对路径目录要提前创建并给 mysql 用户写权限audit_record_objects 记录具体对象访问后面章节会讲它的代价。写完配置要重启 mysqld 让参数生效重启后第一件事是执行 SHOW VARIABLES LIKE audit%; 确认参数都读进来了。3.3 核心参数速查一张表讲清 8 个必调项下表是我部署时逐项核对过的一组参数默认值以实例加载后 SHOW VARIABLES 的实际输出为准这里给的是推荐关注点参数名默认值参考作用与建议audit_json_fileOFF是否输出 JSON 审计日志审计落地必须为 ONaudit_json_log_file空JSON 日志路径必须指向 mysql 可写的目录audit_record_objectsOFF是否记录表级对象访问合规要求建议开audit_log_rotate_on_size0单文件超过该字节数自动轮转配合磁盘容量设定audit_json_buffer_size32768JSON 写入缓冲区日志量大可调大audit_buffer_size1048576审计事件内存缓冲影响高频写入性能audit_whitelist_users空不参与审计的用户名列表逗号分隔audit_uninstall_pluginOFF卸载保护开关设为 ON 才允许 UNINSTALL PLUGIN这里要特别解释 audit_uninstall_plugin它是插件的自我保护默认 OFF 时你 UNINSTALL PLUGIN 会被拒绝这是安全设计不是故障。想卸载时先 SET GLOBAL audit_uninstall_plugin ON; 再执行 UNINSTALL PLUGIN AUDIT; 完事后再设回 OFF它是名副其实的“后悔药”开关。其余参数大多支持 SET GLOBAL 动态调整但只有写进 my.cnf 才会重启后保留线上变更建议先动态调、观察稳定了再固化到配置文件。4. 开箱验证三行 SQL 开启 JSON 审计并用真实查询确认落盘4.1 最小开启命令三行 SQL 让审计立即生效如果你不想立刻重启实例可以先用 SET GLOBAL 动态开启SET GLOBAL audit_json_file ON; SET GLOBAL audit_json_log_file /var/log/mysql-audit/mysql-audit.json; SET GLOBAL audit_record_objects ON;第一行打开 JSON 日志总开关第二行指定落盘文件第三行记录对象访问。注意动态改参数只对当前运行实例生效重启后会回到 my.cnf 里的值所以最终要把这三项写进 [mysqld] 段。在改参数之前日志目录必须先建好并授权不然插件写文件时可能静默失败你等半天也等不到日志mkdir -p /var/log/mysql-audit chown mysql:mysql /var/log/mysql-audit chmod 750 /var/log/mysql-audit注意日志目录必须提前创建并授权否则插件写文件失败不会有任何客户端报错。目录属主和前面 .so 的属主是同一个逻辑mysqld 进程以 mysql 用户运行它写不了的文件插件不会替你报错这是审计插件最容易踩的“无声失败”坑。4.2 用一条业务查询验证日志输出开启后执行一条真实的写操作再回头查日志INSERT INTO test.audit_probe(id, note) VALUES (1, hello-audit);然后到日志目录看最后几行tail -n 5 /var/log/mysql-audit/mysql-audit.json正常情况下会看到类似下面的结构字段顺序和格式以实际版本为准{date:2025-01-01T10:00:00,thread:42,class:INSERT,user:app_user,ip:10.0.0.5,db:test,query:INSERT INTO test.audit_probe ...}逐字段解释date 是执行时间class 是语句类别user 是登录账号ip 是客户端来源db 是默认库query 是完整 SQL。这条记录证明插件已经进入工作状态。如果机器上有 jq还可以做结构化过滤比如统计哪个用户执行量最大jq -r .user /var/log/mysql-audit/mysql-audit.json | sort | uniq -c | sort -rn | head -20这条链路过一遍之后你才算把审计日志从“装上了”推进到“能用了”。4.3 日志轮转与权限别让审计日志把磁盘撑爆全量审计的日志量很可观SELECT 频繁的业务一天写几 GB 是常态。插件自带 audit_log_rotate_on_size 参数可以按大小轮转我一般配合 logrotate 一起用写一个独立配置cat /etc/logrotate.d/mysql-audit EOF /var/log/mysql-audit/mysql-audit.json { daily rotate 30 compress missingok copytruncate su mysql mysql } EOF配置里关键的是 copytruncate插件会一直持有日志文件的写句柄rename 方式轮转会导致插件继续写旧文件copytruncate 先把文件复制一份再清空原文件更适合服务进程持续写入的日志。rotate 30 加 compress 能压住历史体量。执行 logrotate -f /etc/logrotate.d/mysql-audit 手工触发一次确认没有报错再看磁盘变化。这一步做完审计日志才不会被磁盘告警反噬。5. 审计插件避坑记录5 个翻车现场与修复路径5.1 现象INSTALL PLUGIN 报版本错误现象执行 INSTALL PLUGIN AUDIT SONAME libaudit_plugin.so返回类似 plugin ... is for another MySQL version 的错误。原因把 5.7 的包装到了 5.6 或 8.0 实例上或者 .so 本身是其他平台编译的。解决停下安装先 SELECT VERSION(); 确认大版本再去拿对应版本的审计插件包5.7 就用本标题这套 mysql-5.7 包。跨大版本硬装没有后悔药别浪费时间。5.2 现象插件加载成功但日志文件一直不生成现象SHOW PLUGINS 里 AUDIT 状态是 ACTIVEaudit_json_file 也是 ON但指定路径下没有文件。原因日志目录不存在或 mysql 用户对目录没有写权限插件写文件失败但不会在客户端报错。解决按 4.1 的命令创建目录并 chown mysql:mysql再执行两条命令重置写句柄SET GLOBAL audit_json_file OFF; SET GLOBAL audit_json_file ON;然后用 ls -l 确认文件出现。血泪经验先看目录权限再怀疑插件本身。5.3 现象重启后 SHOW PLUGINS 里 AUDIT 消失现象刚装完一切正常重启 mysqld 后 audit% 参数和插件都查不到了。原因只执行了 INSTALL PLUGIN但实例后来做过 mysql 库恢复或部署流程里 my.cnf 没有同步插件加载项mysql.plugin 表里的注册记录丢了。解决把 plugin-load-addAUDITlibaudit_plugin.so 写进 [mysqld] 段这样只要 .so 文件在启动就会尝试加载再配合 INSTALL PLUGIN 双保险。我的习惯是部署时验证一次“重启前 SHOW PLUGINS 和重启后 SHOW PLUGINS 输出一致”。5.4 现象审计日志一天写几十 GB磁盘报警现象开启全量审计后数据盘快速被打满业务 SELECT 也被逐条记录。原因没设轮转也没做用户过滤高频只读账号的 SELECT 全量落盘量级远超预期。解决先配置 logrotate 和轮转参数止损-- 超过 1GB 自动轮转具体值按磁盘容量调整 SET GLOBAL audit_log_rotate_on_size 1073741824;再用 6.1 的 audit_whitelist_users 把内部运维账号、只读账号加进白名单如果还需要细粒度考虑只记录 INSERT、UPDATE、DELETE、DROP 等高危类别缩小记录面。磁盘是硬约束先保证不炸盘再谈完整性。5.5 现象UNINSTALL PLUGIN 被拒绝插件卸载不掉现象想停用审计执行 UNINSTALL PLUGIN AUDIT返回错误插件像锁死了一样。原因audit_uninstall_plugin 参数默认 OFF这是插件刻意做的卸载保护。解决按顺序执行下面两行SET GLOBAL audit_uninstall_plugin ON; UNINSTALL PLUGIN AUDIT;卸载成功后把该参数设回 OFF并同步删掉 my.cnf 里的 plugin-load-add 行否则下次启动又会加载。这个开关是误装后的“后悔药”但操作顺序不能反。6. 进阶调优白名单过滤、敏感对象审计与性能验证6.1 内部账号白名单让监控和备份语句不再刷屏全量审计的第一轮数据噪音很大监控探活、备份账号、复制账号的语句会占掉相当比例。常见做法是跑几小时后先统计日志里的 user 分布再把高频内部账号加进白名单SET GLOBAL audit_whitelist_users root,replica,monitor,backup_user;匹配的是登录账号逗号分隔加白后这些账号产生的语句不再进审计日志。生产环境建议只放行内部运维身份让应用账号保持被审计状态信噪比会好很多。6.2 敏感对象审计audit_record_objects 的取舍与定位audit_record_objects 开启后日志会带上被访问的表对象对追查敏感表泄露很有用但每条语句元数据变多、日志膨胀更快。我的做法是含身份证、支付信息的库开对象级审计普通业务库只按语句类别记录。配合 jq 能快速定位访问过某张表的记录jq -r select(.query | contains(t_user_pay)) | .date .user .ip \ /var/log/mysql-audit/mysql-audit.json | tail -50这条命令把 query 字段包含指定表名的行过滤出来按时间、账号、IP 输出追查时比翻原始日志高效。6.3 性能验证同一套负载审计开关各跑十分钟审计插件的开销集中在事件缓冲和磁盘写入高频小事务场景影响最明显。我现在的习惯是先在测试实例上用压测脚本跑十分钟只读负载记录基线 TPS再开审计跑同样的十分钟对比两次差值下降超过 8% 就调大 audit_buffer_size 和 audit_json_buffer_size再重测直到差值落在可接受区间整个过程二十分钟结论写进变更单。审计日志平时看着占磁盘真出事时它就是证据链值得在安装前多花这一点时间。希望帮到你。本文还有配套的精品资源点击获取