应定期审计权限，揪出高危账户（如SUPER权限），按最小权限原则重授，删账号前先REVOKE，权限表损坏时需备份后重建。
查出谁有“不该有的权限”
权限混乱不是因为人多，而是因为没人定期审计。最危险的不是没权限，而是多给了权限——比如一个应用账号却能 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 后仍不生效、或多个账号同时异常，优先怀疑表损坏，而不是一个个去调权限。
