应优先查询拥有Super_priv、Repl_slave_priv或Grant_priv权限的账号，因其可kill连接、伪造主从、授予权限；再结合host为'%'且DML权限≥3的组合，快速识别高危账号。
如何用 SELECT 快速识别高危账号
MySQL 权限风险往往藏在「看似正常」的账号里。重点不是查谁有 GRANT OPTION，而是查谁拥有能绕过常规限制的能力。直接运行以下语句找出危险组合：
SELECT user, host, IF(Select_priv='Y',1,0) + IF(Insert_priv='Y',1,0) + IF(Update_priv='Y',1,0) + IF(Delete_priv='Y',1,0) AS dml_count, IF(Grant_priv='Y',1,0) AS has_grant, IF(Super_priv='Y',1,0) AS has_super, IF(Repl_slave_priv='Y',1,0) AS has_repl_slave FROM mysql.user WHERE (dml_count >= 3 OR has_grant = 1 OR has_super = 1 OR has_repl_slave = 1);
注意：mysql.user 表权限字段是字符型（'Y'/'N'），不能直接用 = 1；dml_count 是计算列，实际执行需拆成子查询或用 HAVING 过滤。更稳妥写法：
SELECT user, host,
Grant_priv, Super_priv, Repl_slave_priv,
CONCAT('SHOW GRANTS FOR ''', user, '''@''', host, ''';') AS review_cmd
FROM mysql.user
WHERE Grant_priv='Y' OR Super_priv='Y' OR Repl_slave_priv='Y';-
Super_priv='Y'意味着可 kill 任意连接、修改全局变量、绕过sql_mode限制 -
Repl_slave_priv='Y'常被忽略——它允许伪造主从身份，配合LOAD DATA LOCAL INFILE可读取服务器任意文件 - 账号
host为'%'且权限宽松时，必须立即收缩范围，哪怕只改一个host字段也能大幅降低攻击面
为什么 SHOW GRANTS 结果不能直接信
SHOW GRANTS FOR 'u'@'h' 只显示显式授予的权限，不反映角色继承、动态权限（MySQL 8.0+）、或通过 PROXY 机制获得的间接权限。真实权限是叠加结果。
检查角色权限要分两步：
SELECT * FROM mysql.role_edges WHERE TO_HOST = 'your_role_name';
SELECT * FROM mysql.role_edges WHERE FROM_HOST = 'your_role_name';
而动态权限（如 BACKUP_ADMIN、CLONE_ADMIN）不会出现在 mysql.user 表中，得查：
SELECT * FROM mysql.role_edges JOIN mysql.default_roles USING (FROM_HOST, FROM_HOST) WHERE TO_HOST IN (SELECT user FROM mysql.user WHERE user='target_user');
- MySQL 8.0.16+ 才支持动态权限，老版本查
INFORMATION_SCHEMA.APPLICABLE_ROLES会报错 -
SHOW GRANTS不显示SYSTEM_VARIABLES_ADMIN等新权限，但它们能让用户修改secure_file_priv或log_bin，直接影响安全边界 - 如果账号被赋予了角色，又单独授了同名权限（比如
SELECT），撤销角色不会自动撤掉该权限——得手动清理残留
自动化审计脚本该监控哪些变更点
权限风险不是静态的，关键在于「谁在什么时候改了什么」。MySQL 自身不记录细粒度 DCL 日志，必须靠外部手段捕获：
- 开启
general_log并过滤含GRANT、REVOKE、CREATE USER、DROP USER的行（仅临时启用，性能代价大） - 用
performance_schema监控语句事件（MySQL 5.7+）：SELECT THREAD_ID, EVENT_NAME, SQL_TEXT FROM performance_schema.events_statements_history_long WHERE SQL_TEXT REGEXP '^(GRANT|REVOKE|CREATE USER|DROP USER)';
- 生产环境推荐：在代理层（如 ProxySQL、MaxScale）或接入网关统一拦截 DCL 语句，打标后发到 SIEM
真正要告警的不是「有 GRANT」，而是：
- 非运维时段（如凌晨 2–4 点）出现
GRANT ALL ON *.* - 普通业务账号突然被赋予
REPLICATION SLAVE - 同一账号在 5 分钟内连续执行超过 3 次
GRANT
权限回收时最常踩的三个坑
删权限不是删数据，操作不当会导致服务中断或权限残留：
-
REVOKE INSERT ON db.* FROM 'u'@'%'不会清除该用户从角色继承的INSERT权限——必须先REVOKE role FROM 'u'@'%'，再REVOKE显式权限 -
DROP USER 'u'@'%'在 MySQL 8.0.12+ 默认级联删除角色授权，但若用户是某角色的ADMIN OPTION持有者，角色本身不会被删，只是失去管理权 - 用
mysqldump --no-data --routines --triggers mysql备份权限表时，mysql.role_edges和mysql.default_roles不会被包含，必须显式导出
最小权限原则不是一句口号：每次回收前，用 SELECT COUNT(*) FROM information_schema.TABLE_PRIVILEGES 确认当前库表级权限总数，回收后再比对，避免误删导致应用报 ERROR 1142 (42000)。
