查出谁有“不该有的权限”
权限混乱不是因为人多，而是因为没人定期审计。最危险的不是没权限，而是多给了权限——比如一个应用账号却能
DROP DATABASE，或一个开发账号拥有
SUPER权限。
SELECT user, host, authentication_string FROM mysql.user;看所有账号是否存在空密码、弱密码或长期未更新的凭证
SELECT * FROM mysql.user WHERE Super_priv='Y' OR Grant_priv='Y' OR Create_user_priv='Y';一眼揪出能越权授予权限的“高危账户”
SHOW GRANTS FOR 'app_rw'@'%';逐个验证关键账号的实际权限，特别注意是否出现
ALL PRIVILEGES ON *.*或对
mysql库的写权限
用最小权限重授，别再 GRANT ALL
给权限就像发钥匙——只给开自己门的那一把。
GRANT ALL ON app_db.*看似省事，实则埋雷：一旦账号泄露，攻击者可
ALTER TABLE、
TRUNCATE、甚至注入恶意触发器。 应用只读账号：仅
GRANT SELECT ON app_db.orders TO 'app_ro'@'%';，禁止跨库、禁列级授权（除非真需要） 应用读写账号：显式列出
SELECT, INSERT, UPDATE, DELETE，**不加
GRANT OPTION**，且避免
ON *.*—— 改为
ON app_db.*运维账号：限定内网 IP（如
'dba'@'10.10.20.%'），只开放
PROCESS、
REPLICATION CLIENT、
SHOW VIEW，禁用
FILE和
SHUTDOWN
删账号前先 REVOKE
，别直接 DROP USER
直接
DROP USER会跳过权限回收步骤，若该用户权限曾被
GRANT ... WITH GRANT OPTION授出，下游账号可能残留悬空权限，导致后续审计失真。 先清空权限：
REVOKE ALL PRIVILEGES ON *.* FROM 'legacy_user'@'%';，再
REVOKE GRANT OPTION ON *.* FROM 'legacy_user'@'%';确认无活跃连接：
SELECT id, user, host, command, time FROM information_schema.processlist WHERE user = 'legacy_user';，有则
KILL掉 最后执行：
DROP USER 'legacy_user'@'%';，MySQL 8.0+ 会自动清理角色关联，5.7 需手动检查
mysql.role_edges（若模拟角色）
修复权限表损坏：别手改 mysql.user
当
SHOW GRANTS显示权限存在，但实际操作仍报
Access denied；或新建用户后
SELECT * FROM mysql.user查不到记录——大概率是权限表结构损坏或缓存脱节，不是配置错，更不是密码错。 先确认是否误启过
--skip-grant-tables：
SELECT @@skip_grant_tables;返回
ON就得警惕 备份再动刀：
mysqldump --single-transaction --databases mysql > mysql_backup_$(date +%F).sql，**必须全库导出**，单导
user表会丢掉
db、
tables_priv关联 停服务后重建：
bin/mysqld --initialize-insecure --user=mysql --datadir=/var/lib/mysql—— 它重刷的是权限表结构和默认 root 密码为空，**不会碰你的业务库**
真正难的不是操作，是判断“这到底是权限配错了，还是权限系统本身坏了”。只要
FLUSH PRIVILEGES后仍不生效、或多个账号同时异常，优先怀疑表损坏，而不是一个个去调权限。
