mysql权限配置风险的本质是“过度授权”，即账号获得超出业务所需的权限，如只读账号拥有grant option或drop权限，虽不致服务崩溃，却会加剧横向渗透或误操作风险。
mysql权限配置风险的本质是“过度授权”
MySQL 权限风险不是靠有没有报错来判断的，而是看账号是否拿到了它本不需要的权限。比如一个只读应用账号拥有 GRANT OPTION 或 DROP 权限，就是典型风险。这类问题不会让服务崩掉，但会显著放大被横向渗透或误操作的影响。
用 mysqlpump + 自查 SQL 快速筛高危权限
官方没有“一键扫描工具”，但可以用组合命令快速定位异常配置。核心思路是：导出所有非内置用户的权限语句，再 grep 关键词。
- 先执行：
mysqlpump --no-data --skip-definer --users > /tmp/users.sql 2>/dev/null（需有SELECT权限访问mysql.user和mysql.db） - 然后检查：
grep -E "(GRANT OPTION|SUPER|FILE|SHUTDOWN|PROCESS|REPLICATION CLIENT|REPLICATION SLAVE)" /tmp/users.sql - 重点关注非 DBA 账号是否持有这些权限——尤其是
FILE（可读写服务器任意文件）、SUPER（可绕过大多数限制）
SHOW GRANTS 查单个账号时容易漏掉角色继承权限
MySQL 8.0+ 支持角色（ROLE），而 SHOW GRANTS FOR 'u'@'h' 默认只显示直接授予的权限，不包含该用户被赋予的角色所带的权限。
- 要查完整权限，得加
USING子句：SHOW GRANTS FOR 'u'@'h' USING 'role_name' - 更稳妥的方式是查视图：
SELECT * FROM role_edges WHERE TO_HOST = 'u'@'h'，再连查role_table_privs和role_column_privs - 很多安全扫描脚本忽略角色链，导致误判“权限干净”，实际可能通过角色间接拿到
ALL PRIVILEGES ON *.*
第三方扫描工具（如 mysql-audit、gosec 插件）的兼容性陷阱
市面上所谓“MySQL 安全扫描工具”多数是包装了基础 SQL 查询，真正要注意的是 MySQL 版本和部署形态带来的偏差。
-
mysql-audit插件只支持 5.7.17+ 且必须手动安装，8.0.21+ 后默认禁用，启用前要确认audit_log_policy配置是否生效 - 云数据库（如阿里云 RDS、AWS RDS）通常屏蔽
mysql.user直接访问，SELECT会报ERROR 1142 (42000): SELECT command denied，此时只能依赖控制台提供的权限审计日志 - 任何扫描工具若声称“自动修复权限”，一律跳过——权限回收必须人工确认业务影响，比如删掉
USAGE可能导致连接池初始化失败
权限配置的风险不在语法对错，而在授权范围与最小必要原则之间的偏差。最常被忽略的是：角色继承、云环境受限视图、以及 PROXY 权限这类隐式提权路径。
