直接查mysql.user表中super_priv、repl_slave_priv、grant_priv为'y'的账号，执行select user, host, super_priv, repl_slave_priv, grant_priv from mysql.user where super_priv = 'y' or repl_slave_priv = 'y' or grant_priv = 'y';，再逐个验证show grants并补查角色继承、动态权限及proxy权限。
查谁有Super_priv、Repl_slave_priv这些高危权限
直接查 mysql.user 表里标记为 'Y' 的字段，但别只看 Super_priv ——Repl_slave_priv 和 Grant_priv 同样危险：Repl_slave_priv 可伪造从库身份读取任意文件，Grant_priv 能给其他人授予权限，形成权限扩散链。
执行这条语句快速定位：
SELECT user, host, Super_priv, Repl_slave_priv, Grant_priv FROM mysql.user WHERE Super_priv = 'Y' OR Repl_slave_priv = 'Y' OR Grant_priv = 'Y';
-
Super_priv='Y'意味着能执行SET GLOBAL、KILL、INSTALL PLUGIN等操作，必须严格限制 host（比如只允许'localhost'或运维跳板机 IP） -
host是'%'的高危账号，哪怕只有SELECT权限也应优先收缩，因为攻击者可从任意 IP 连入尝试爆破或利用漏洞 - 结果里的每个账号都要立刻执行
SHOW GRANTS FOR 'user'@'host';，确认是否真需要这些权限，而不是历史遗留的“默认全开”
为什么 SHOW GRANTS 结果不能直接信
SHOW GRANTS FOR 'u'@'h' 只显示显式授予的权限，漏掉三类真实生效的权限：角色继承、动态权限（MySQL 8.0+）、PROXY 用户代理权限。一个用户可能没在 mysql.user 表里标 Super_priv='Y'，却通过角色获得了等效能力。
必须补查：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 角色继承关系：
SELECT * FROM mysql.role_edges WHERE TO_HOST = 'target_role';（查谁被赋予了该角色），再查FROM_HOST = 'target_role'（查该角色本身有哪些权限） - 动态权限：
SELECT * FROM information_schema.role_table_grants WHERE grantee = "'user'@'host'";或直接查performance_schema.global_grants（MySQL 8.0.16+） - PROXY 权限：
SELECT * FROM mysql.proxies_priv WHERE Host = 'host' AND User = 'user';，若存在且Grant_priv='Y'，说明可通过代理获得目标用户权限
server_audit 插件怎么配才真正捕获高危操作
只开 server_audit_logging = ON 不够，很多团队配完发现日志里没有 SET GLOBAL 或 INSTALL PLUGIN 记录——问题出在事件过滤没设对。
关键配置必须同时满足：
-
server_audit_events必须包含QUERY_DDL（否则SET GLOBAL、CREATE USER等不会记），推荐值：'CONNECT,QUERY_DDL,QUERY_DML' -
performance_schema必须开启（SHOW VARIABLES LIKE 'performance_schema';返回ON），否则部分上下文（如客户端 IP、线程 ID）缺失 -
server_audit_excl_users别乱加 DBA 账号，比如写成'root,dba_admin'就等于审计失效；只排除监控账号（如'monitor'） - 日志路径权限要检查：
chown mysql:mysql /var/log/mysql/audit.log，否则插件静默失败不报错
audit_log 配置后为什么日志还是空的
最常卡在这三个地方：
- 没确认插件是否真正加载：
SHOW PLUGINS;查server_audit状态是不是ACTIVE；如果显示DISABLED，先运行INSTALL PLUGIN server_audit SONAME 'server_audit.so';（注意路径和文件名匹配） -
server_audit_events漏了CONNECT—— 导致连谁登录、从哪登录都看不到，根本没法关联后续操作 - MySQL 配置文件（
my.cnf）里写了server_audit_logging=ON，但没重启 mysqld，或者只执行了SET GLOBAL（重启后失效）
真正生效的配置必须写进 my.cnf 的 [mysqld] 段，并重启服务；临时设置仅用于验证，不能替代持久化配置。
