MySQL 8.0+ 中 AUDIT_ADMIN 是全局权限而非账号类型，仅用于启停审计插件，不可授予审计人员；审计员只需 SELECT 权限读取审计表或 OS 文件读取权限，且须禁用 SHOW DATABASES 等高危权限并强制 SSL 连接。
MySQL 8.0+ 中没有内置的 AUDIT_ADMIN 账号类型，也没有“审计管理员”角色概念；所谓 AUDIT_ADMIN 是一个全局权限（privilege），不是账号类型，且它只用于管理审计插件本身，不用于查日志。
为什么不能直接 GRANT AUDIT_ADMIN 给审计人员
很多人看到文档里有 AUDIT_ADMIN 权限，就以为授予它就能让某人“当审计管理员”。这是典型误解：
-
AUDIT_ADMIN允许执行INSTALL PLUGIN audit_log、SET GLOBAL audit_log_policy = 'ALL'等操作——本质是“开关审计功能”，不是“查看审计内容” - 授予该权限的账号可停用整个审计系统，违背三权分立中“审计不可被干预”的原则
- MySQL 官方明确建议：该权限应仅由安全管理员（
security_admin）持有，审计人员必须 完全不拥有 它 - 如果你给
audit_admin账号加了AUDIT_ADMIN，等于把审计开关交到审计员自己手里，等保整改会直接不通过
审计人员真正需要的是什么权限
审计人员要做的只有一件事：**读取已产生的审计记录**。这取决于你用哪种方式落地审计日志：
- 若使用 MySQL 企业版或
audit_log插件（日志写入文件）：审计人员不需要数据库权限，只需操作系统级文件读取权限（如/var/lib/mysql/audit.log），但需配合日志轮转与访问控制 - 若使用自建审计表（如
audit_db.access_log）：只需对这张表有SELECT权限，且 不能有INSERT/UPDATE/DELETE - 若依赖
performance_schema行为追踪（如events_statements_history_long）：必须显式授权SELECT ON performance_schema.*，因为默认禁止普通用户访问该库 - 绝对禁止授予
SHOW DATABASES、PROCESS、INFORMATION_SCHEMA查询权——这些会让审计员看到所有库名、连接线程、SQL 执行计划，属于元数据泄露
创建合规的 audit_admin 账号实操步骤
以审计日志存于 audit_db.access_log 表为例，正确创建流程如下：
- 用
CREATE USER创建账号，并强制 SSL：CREATE USER 'audit_admin'@'%' IDENTIFIED BY 'StrongPass!2026' REQUIRE SSL; - 只授 SELECT 权限：
GRANT SELECT ON `audit_db`.`access_log` TO 'audit_admin'@'%'; - 显式回收高危权限（防继承或残留）：
REVOKE SHOW DATABASES, PROCESS, SUPER ON *.* FROM 'audit_admin'@'%'; - 用
ALTER USER替代FLUSH PRIVILEGES，确保权限立即生效：ALTER USER 'audit_admin'@'%' PASSWORD EXPIRE INTERVAL 90 DAY; - 验证权限是否干净：
SHOW GRANTS FOR 'audit_admin'@'%';输出应只含SELECT且无通配符（如ON *.*）
容易被忽略的关键点
最常出问题的地方不在 SQL 语句本身，而在配套配置：
- 服务端
have_ssl必须为YES，否则REQUIRE SSL形同虚设；检查命令：SHOW VARIABLES LIKE 'have_ssl'; - 客户端连接时必须带
--ssl-mode=REQUIRED，否则即使服务端要求 SSL，MySQL 客户端默认仍可能走明文连接 - 审计表所在的库（如
audit_db）不能被其他账号误授ALL PRIVILEGES，否则权限会覆盖细粒度控制 - 如果用了
validate_password组件，audit_admin的密码策略需单独设置，避免因策略过严导致无法定期改密
