mysql社区版默认无合规审计能力，需手动安装server_audit.so插件并配置日志路径、旋转策略及chattr+rsyslog防篡改；企业版audit_log须分级过滤账号与操作，禁用all策略。
MySQL社区版默认不带合规级审计能力，必须依赖插件；企业版用audit_log，社区版得选server_audit.so（MariaDB）或audit_log_filter.so（MySQL 8.0+），否则日志颗粒度、防篡改、策略过滤三项全不达标。
确认当前MySQL是否支持audit_log插件
企业版用户先执行：SHOW PLUGINS; 或 SELECT * FROM information_schema.PLUGINS WHERE PLUGIN_NAME = 'audit_log';。若状态不是ACTIVE，说明插件未加载——别急着改配置，先查plugin_dir路径：SHOW VARIABLES LIKE 'plugin_dir';，再确认该目录下是否存在audit_log.so文件。社区版执行这两条命令大概率返回空，直接跳到下一节。
社区版用server_audit.so实现等保三级基础要求
这是目前最稳妥的开源方案，尤其适配VPS或轻量生产环境：
- 下载匹配MySQL版本的
server_audit.so（MariaDB官网提供，注意选与MySQL主版本一致的分支，如MySQL 8.0.33对应MariaDB 10.11.x） - 复制到
plugin_dir后，执行：INSTALL PLUGIN server_audit SONAME 'server_audit.so'; - 关键配置写入
my.cnf的[mysqld]段：server_audit_logging=ONserver_audit_events='connect,query,table'server_audit_file_path=/var/log/mysql/server-audit.logserver_audit_file_rotate_size=524288000（500MB）server_audit_file_rotations=10 - 切记：日志路径不能在
datadir下，否则MySQL重启时可能被清空；属主设为mysql:auditlog，权限640
audit_log_policy=ALL不是万能解，反而容易踩性能和合规双坑
企业版启用audit_log后，很多人直接设audit_log_policy=ALL，结果发现两件事：
— 日志里只记了SQL语句文本，PASSWORD、SSN这类敏感值原样明文落盘，数据库层根本不脱敏；
— 高并发下写日志变成瓶颈，audit_log_strategy设asynchronous也压不住延迟，部分查询超时。
真正合规的做法是分级控制：
- 用
audit_log_include_accounts只审计admin@%、etl_user@10.0.0.%等关键账号，排除监控账户自身操作 - DDL操作必须全量记录，但
SELECT类查询可按库过滤：audit_log_exclude_tables='information_schema.*,performance_schema.*' - 敏感字段访问靠应用层埋点或中间件拦截，数据库只负责打标（例如在SQL注释里加
/* SENSITIVE:customer_id */），审计系统再解析
日志不可篡改不是靠chmod，而是靠chattr +a和异地同步
合规审查最常卡在“日志能否被DBA删改”这一项。仅设文件权限640没用，root或mysql用户仍可覆盖。必须做两件事：
- 对日志文件执行：
chattr +a /var/log/mysql/server-audit.log，使其只能追加，不能删除/截断/重命名 - 用
rsyslog或filebeat实时把新日志行推送到独立日志服务器，本地不留副本；若需区块链存证，哈希值应在日志生成后立即计算并上链，而非事后补 - 轮转后的旧日志文件（如
server-audit.log.1.gz）要立刻移出MySQL主机，否则仍算“本地可访问”
最容易被忽略的是时间戳精度和时区一致性：所有节点必须NTP对时，且日志中时间字段必须带时区偏移（如"timestamp":"2026-06-04T11:50:22.123+08:00"），否则跨地域审计比对会失效。
