等保三级要求严格管控高权限账号：super_priv='y'可绕过审计执行关键操作；grant option分散存储难追溯；host为'%'的账号因未限定来源被判高风险；show grants结果不等于实际权限，存在角色继承、列级授权、过程权限及隐式叠加等复杂叠加效应。
MySQL中Super_priv权限会绕过所有访问控制规则
拥有Super_priv='Y'的账号能执行KILL任意连接、修改全局变量（如sql_mode、max_connections）、禁用只读模式，甚至绕过SQL_LOG_BIN=0限制直接写binlog。等保三级明确要求“关键操作不可绕过审计”，而这类行为在general_log或server_audit中可能不被记录，或仅记为“SET”语句，无法还原真实意图。
GRANT OPTION权限比Super_priv更难审计
GRANT OPTION不会出现在mysql.user表字段里，它分散在mysql.db、mysql.tables_priv甚至mysql.procs_priv中。一个'dev'@'%'账号即使没Super_priv，只要带GRANT OPTION，就能给任意新账号授予DROP TABLE或FILE权限——而这些子账号的操作日志，往往不关联到原始授权者，导致责任无法追溯。
host为'%'的高权限账号在等保检查中直接被判高风险
- 等保三级要求“管理账号必须限定登录来源”，
'root'@'%'或'dba'@'192.168.%'这类配置会被扫描工具直接标红 - 合规检查脚本通常运行类似语句：
SELECT user, host FROM mysql.user WHERE Super_priv='Y' AND host LIKE '%'; - 即使你用
REQUIRE X509做了证书认证，只要host字段是通配符，多数等保工具仍按“未收敛访问源”扣分
SHOW GRANTS结果不等于实际生效权限
开发者常误以为SHOW GRANTS FOR 'dev'@'10.20.30.40'输出就是全部权限，但真实权限是叠加效果：
- 角色继承：如果
'dev'被赋予了'backup_admin'角色，而该角色有BACKUP_ADMIN动态权限，SHOW GRANTS不会显示 - 列级权限：
SELECT (id,name) ON app.users和SELECT (phone,email) ON app.users是两条独立授权，SHOW GRANTS合并成一行，但审计时需逐列确认是否越权 - 存储过程EXECUTE权限可能来自
mysql.procs_priv，而非库级EXECUTE，漏查就等于放行敏感逻辑调用
Repl_slave_priv='Y'本身不显眼，但它配合LOAD DATA LOCAL INFILE可读取服务器任意文件，而这个能力又依赖local_infile系统变量是否开启，变量权限又受Super_priv控制。链条一长，人工审计极易断点。
