必须先查清权限继承链再执行REVOKE；MySQL 8.0不会自动清理DROP USER后的权限残留，需用REVOKE显式回收并验证role_edges等表是否为空，角色清理须先解绑再DROP ROLE。
REVOKE 之前必须先查清权限继承链
MySQL 8.0 不会自动清理被 DROP USER 删除用户的权限残留，尤其当该用户曾用 WITH GRANT OPTION 授出权限时，下游用户可能仍持有“无主”的权限对象。直接删账号会导致权限审计断链，甚至出现 Access denied 却查不到对应 GRANT 记录的诡异现象。
执行前务必确认依赖关系：
-
SELECT * FROM mysql.role_edges WHERE from_user = 'legacy_user' AND from_host = '%';—— 查谁从该用户继承了角色 -
SELECT * FROM mysql.db WHERE User = 'legacy_user';—— 查库级权限是否还挂在其名下 -
SELECT * FROM mysql.tables_priv WHERE User = 'legacy_user';—— 查表级权限残留
注意：这些查询需以高权限账号（如 root）执行，且 MySQL 8.0+ 系统表默认为 InnoDB 引擎，支持事务一致性读。
用 REVOKE 显式回收比 DELETE 系统表行更安全
看到 mysql.user 表里还有旧用户记录，别手痒 DELETE FROM mysql.user WHERE User = 'legacy_user'。这种绕过权限校验机制的直改，会导致内存缓存与磁盘状态脱节，FLUSH PRIVILEGES 也救不回来，极大概率触发后续所有权限判断异常。
正确做法是分步 REVOKE：
REVOKE ALL PRIVILEGES ON *.* FROM 'legacy_user'@'%';REVOKE GRANT OPTION ON *.* FROM 'legacy_user'@'%';- 若该用户曾授出角色：
REVOKE 'app_reader' FROM 'legacy_user'@'%';
每条 REVOKE 都会同步更新系统表并刷新内存缓存，比手动删行多一层校验和事务保障。MySQL 8.0 的 REVOKE 是原子操作，失败则全部回滚。
SHOW GRANTS 显示为空 ≠ 权限已清空
执行完 REVOKE 和 DROP USER 后，运行 SHOW GRANTS FOR 'legacy_user'@'%' 报错或返回空，不代表权限彻底消失。因为：
- 若该用户曾把角色授予他人，
role_edges表中仍有指向它的记录，下游用户权限实际未失效 - 某些旧版本（如 5.7 兼容模式下部署的 8.0 实例）可能残留
mysql.procs_priv或mysql.columns_priv中的孤立条目 -
SHOW GRANTS默认不显示角色继承权限，必须加USING子句才能验证全量效果
验证是否真干净，得查下游：
SELECT TO_USER, TO_HOST, FROM_USER, FROM_HOST FROM mysql.role_edges WHERE FROM_USER = 'legacy_user'; —— 返回空才表示角色链已断
MySQL 8.0 角色清理要两步走：解绑 + 删除
如果 legacy_user 是个角色（比如 CREATE ROLE 'db_analyst';），不能只删用户，角色本身也得处理。角色不是用户，不会登录，但它是权限容器，残留后可能被误授给新用户。
清理步骤固定：
- 先解除所有绑定：
REVOKE 'db_analyst' FROM 'dev1'@'%', 'dev2'@'%'; - 再删角色本身：
DROP ROLE 'db_analyst';
注意：DROP ROLE 在 MySQL 8.0.16+ 才支持；低于此版本只能靠 DELETE FROM mysql.role_edges + FLUSH PRIVILEGES，但风险高，不推荐。
真正麻烦的从来不是删掉一个名字，而是确认它没在任何地方悄悄起作用——尤其是那些没人记得、没文档标注、却还在 role_edges 里躺着的授权关系。
