不能直接按用户过滤开启审计日志，mysql原生audit_log插件仅支持all、logins、queries策略，无user-level白名单参数；需全量记录后通过json字段"user"或newline格式第3列用grep/jq/awk筛选，或改用server_audit插件配合excl_users排除特定用户，关键操作追溯应依赖binlog_rows_query_log_events=on的row格式binlog。
不能直接按用户过滤开启审计日志——MySQL原生机制不支持“只记录某几个用户”的动态白名单式审计；必须靠插件能力或日志后处理实现，否则只能全量记录再筛。
audit_log 插件不支持 user-level 过滤，但能用 policy + 后置解析补救
MySQL 8.0+ 自带的 audit_log 插件没有 audit_log_users 或类似参数。它只有 audit_log_policy（值为 ALL、LOGINS、QUERIES），无法指定用户名列表。
- 启用后所有用户操作都会被记录，哪怕你只想盯住
app_admin和etl_job - 真正可行的路径是：先全量记录 → 再用
grep、jq或日志系统（如 Filebeat + Elasticsearch）按user字段过滤 - JSON 格式日志里每条都有
"user": "app_admin@10.0.2.15"字段，结构清晰，适合程序提取 - 若用
NEWLINE格式，字段以 tab 分隔，第 3 列是 user@host，也能awk -F'\t' '$3 ~ /app_admin@/ {print}' audit.log
server_audit 插件支持 event-level 用户过滤，但需手动配置规则
MariaDB 的 server_audit 插件（兼容 MySQL）比 audit_log 更灵活，可通过 server_audit_events 和配套变量控制粒度，但它依然不支持“只审计用户 A”，而是靠组合条件缩小范围。
- 安装后设置：
server_audit_events = connect,query,table，再加server_audit_excl_users = 'root,backup'（排除某些用户） - 注意：
server_audit_incl_users在多数版本中并不存在；官方文档明确只提供_excl_参数，想“包含”只能靠日志后过滤 - 它能记录 IP、时间戳、SQL 文本、返回状态（
status=0表示成功，非 0 是失败），这对定位误操作很关键 - 日志写入文件时默认不加密，敏感 SQL（如含密码的
INSERT）会明文出现，务必限制/var/log/mysql/audit.log权限为600且属主为mysql
binlog + rows_query_log_events 是唯一能反向锁定“谁删了哪行”的方案
如果你的真实目标是追溯误删、误更新，而不是泛泛记录“谁连过库”，那 binlog 配合特定参数才是不可替代的路径——它不依赖插件，且能还原到具体数据行。
- 必须满足三个条件：
binlog_format = ROW、binlog_row_image = FULL、binlog_rows_query_log_events = ON - 缺一不可：少了
binlog_rows_query_log_events，你就看不到USER app_user@192.168.1.100这行关键信息；少了FULL，被删行的完整旧值可能缺失 - 解析时用：
mysqlbinlog --base64-output=DECODE-ROWS -v --start-datetime='2026-06-04 15:20:00' /var/lib/mysql/mysql-bin.000022 | grep -A 10 -B 2 'DELETE_ROWS_EVENT\|USER.*app_user' - 注意时区：
mysqlbinlog解析的时间是 UTC，而你的SHOW VARIABLES LIKE 'time_zone'可能是+08:00，查日志前得换算
真正难的不是开日志，而是让日志内容可定位、可验证、不可篡改。比如 audit_log_file 路径写错、权限没给对、JSON buffer 太小导致长 SQL 截断——这些细节不出问题时没人注意，一出就是查无可查。
