MySQL 8.0社区版audit_log插件的DATABASE策略无效，因日志在SQL解析前写入，无法识别库上下文；需组合server_audit插件、触发器和日志后处理实现库级敏感操作审计。
MySQL 8.0 社区版无法用 audit_log 插件直接按数据库过滤敏感操作——它只支持全局策略（ALL、USER、DATABASE），但 DATABASE 策略实际不生效，日志里仍会记录所有库的操作。真要监控“特定数据库”的敏感操作，得组合使用插件 + 触发器 + 日志后处理。
为什么 audit_log_policy=DATABASE 不起作用
官方文档写支持 DATABASE 级策略，但实测 MySQL 8.0.33+ 社区版中该选项形同虚设：启用后日志仍记录全实例所有语句，且无字段标识语句作用于哪个库。根本原因是 audit_log 插件在解析 SQL 前就已触发日志写入，无法动态提取 USE db_name 或库前缀（如 mydb.users）做判断。
-
audit_log_policy=USER只能按账号过滤，不能按库 -
audit_log_include_current_user=ON仅增加用户名字段，不带库上下文 - 企业版的
AUDIT POLICY语法（如ACTIONS ALL ON accounting.*）社区版不识别，执行报错Unknown system variable 'audit_policy'
用 server_audit 插件 + event 过滤实现库级聚焦
社区版最可行路径是换用 MariaDB 的 server_audit 插件（兼容 MySQL 8.0），它虽不原生支持库名过滤，但能把完整 SQL 写进日志，后续可用 grep 或脚本提取目标库操作。
- 必须启用
server_audit_events=query，否则日志只有连接事件，没有 SQL - SQL 中若含库名前缀（如
UPDATE finance.users SET ...），日志里会原样保留；但隐式 USE 后的语句（如先USE finance再UPDATE users）不会自动补前缀，需靠应用层规范写法 - 日志路径设为可读文件（
server_audit_output_type=file），避免写进表后难过滤 - 启动后检查
/var/log/mysql/server_audit.log是否有类似QUERY 12345 root@localhost use finance; UPDATE users...的行
对敏感表变更做精准审计：用触发器补位
如果目标是“某库中几张敏感表的 INSERT/UPDATE/DELETE”，触发器比日志过滤更可靠——它不依赖 SQL 写法，只要 DML 真正执行，就一定触发。
- 在目标表上建
BEFORE INSERT/UPDATE/DELETE触发器，写入自定义审计表（如audit_sensitive_log），字段含table_name、operation、user()、NOW()、OLD/NEW值快照 - 触发器里用
IF (SELECT COUNT(*) FROM information_schema.schemata WHERE schema_name = DATABASE()) > 0确保只在目标库生效（防跨库误触） - 注意性能：高频写入表加触发器会拖慢 DML，建议只对真正敏感的表（如
users、payment_records）启用 - 审计表本身设
ENGINE=Archive或定期归档，避免膨胀
生产环境必须绕开的坑
日志文件权限和字符集问题最常导致漏记或乱码，不是配置没生效，而是 MySQL 进程根本写不进去或写错字节。
-
server_audit_file_path目录必须属主mysql:mysql，且 MySQL 进程有写权限（chown mysql:mysql /var/log/mysql） - 若 SQL 含中文，
server_audit默认用 latin1 编码写日志，中文变问号——需在 my.cnf 加character-set-server=utf8mb4并重启 -
max_allowed_packet小于 4M 时，长 SQL（如大批量 INSERT）会被截断，日志里只剩开头几十个字符 - socket 连接用户（如
root@localhost）可能被server_audit忽略，需确认插件是否启用local事件类型
真正落地时，别指望单靠一个配置开关就搞定“特定数据库敏感操作监控”。server_audit 日志提供原始素材，触发器捕获关键变更，而 grep + 定时脚本才是最终把 finance 库的 DROP TABLE 挑出来的实际工具——三者缺一不可，且每层都要验证是否真在生效。
