DBA账号不能直接授予AUDIT_ADMIN权限，因其本质是启停审计功能而非查看日志；等保要求审计不可干预，该权限须由安全管理员独占持有。
DBA账号不能直接授予AUDIT_ADMIN权限
这是最常踩的坑：把 AUDIT_ADMIN 当成“审计查看权”授予DBA，结果等于给了他们关闭整个审计系统的开关。该权限只允许执行 INSTALL PLUGIN audit_log、SET GLOBAL audit_log_policy = 'ALL' 等操作，本质是“启停审计功能”，不是“读日志”。等保整改明确要求审计不可被干预，所以 AUDIT_ADMIN 必须由安全管理员（非DBA）独占持有。
DBA需要的是分场景的SELECT权限+受限元数据访问
DBA日常查审计日志，实际依赖的是底层存储方式：
- 若用 Percona
audit_log插件写文件（如/var/log/mysql/audit.log）：DBA不需要数据库权限，只需 Linux 文件读取权限 +tail -f或less工具，但必须确保该路径不被其他用户写入或删除 - 若审计日志存进表（如
audit_db.access_log）：只授SELECT，且显式REVOKE SHOW DATABASES, PROCESS, SUPER，否则 DBA 能看到所有库名、线程状态甚至未脱敏的 SQL 执行计划 - 若查
performance_schema.events_statements_history_long：必须单独GRANT SELECT ON performance_schema.*，因为默认禁止普通用户访问该库；同时限制查询时间窗口（如加WHERE event_time > DATE_SUB(NOW(), INTERVAL 1 HOUR)），避免全表扫描拖慢实例
不同DBA角色对应不同审计级别访问范围
不能一刀切给所有人相同权限。按职责区分更安全：
- 主库DBA：可查全部审计表 + 允许访问
information_schema.PROCESSLIST（用于定位慢查询源头），但禁止SELECT * FROM mysql.user - 备库DBA：仅限查
audit_db.access_log中event_type = 'CONNECT'和'QUERY'记录，且加WHERE db = 'prod_app'限定库名 - 值班DBA（on-call）：只开放最近2小时日志的
SELECT权限，且 SQL 中强制包含LIMIT 100，防误操作拉全量 - 所有DBA账号必须
REQUIRE SSL创建，并启用密码过期策略（PASSWORD EXPIRE INTERVAL 90 DAY）
audit_log_policy设置必须与DBA权限解耦
审计级别（audit_log_policy）是全局配置项，由安全管理员通过配置文件或 SET PERSIST 修改，DBA无权变更。常见错误是让DBA用 SET GLOBAL audit_log_policy = 'QUERIES' 临时调高级别——这会绕过审批流程，且无法审计该操作本身。
真正可控的做法是：预设多套配置模板（如 audit_policy_prod.cnf、audit_policy_debug.cnf），由安全团队统一部署；DBA只能通过只读视图（如 audit_vw_recent_activity）查询结果，看不到原始参数值。
复杂点在于：审计日志格式（audit_log_format = JSON）和字段截断（audit_log_max_sqltext = 2048）会影响DBA能看见多少SQL内容，这些参数同样不能由DBA调整，否则可能无意中掩盖敏感操作。
