drop user后权限残留是因为mysql权限系统多表联动，手动删表或历史不一致导致mysql.db等表存在悬空记录；需验证mysql.user和mysql.db等表为空，并清理mysql.role_edges孤立边，再flush privileges。
为什么 DROP USER 后权限还“残留”？
不是 DROP USER 没生效，而是 MySQL 的权限系统由多张表协同维护：mysql.user、mysql.db、mysql.tables_priv、mysql.role_edges 等。如果之前用 DELETE FROM mysql.user 手动删过用户，或升级迁移过程中存在历史数据不一致，就可能让 mysql.db 里还存着 User = 'xxx' 的行——这些记录指向一个已不存在的账号，形成悬空权限。新连接虽无法登录，但旧连接仍可用，甚至重建同名用户时会意外继承这些残留权限。
验证是否真删干净：两步必查
执行 DROP USER 'u'@'h' 后，立刻验证两处：
-
SELECT User, Host FROM mysql.user WHERE User = 'u' AND Host = 'h';—— 必须返回空结果 -
SELECT * FROM mysql.db WHERE User = 'u' AND Host = 'h';（同样检查mysql.tables_priv、mysql.columns_priv、mysql.proxies_priv）—— 这些也必须为空
若任一查询有返回，说明存在残留。注意：Host 字段可能为 ''（空字符串），尤其在老版本升级到 8.0 后未清理干净时，需额外查 SELECT * FROM mysql.db WHERE User = 'u' AND Host = '';
MySQL 8.0+ 特别要扫清角色边（role_edges）
角色机制让清理更隐蔽：DROP USER 会解绑角色，但若 mysql.role_edges 表中存在孤立边（如 FROM_USER 已删，TO_USER 还在），就会留下逻辑脏数据，后续审计或权限同步工具可能误判。
查这类残留：SELECT * FROM mysql.role_edges WHERE FROM_USER = 'u' AND FROM_HOST = 'h';
清理方式只有手动删：DELETE FROM mysql.role_edges WHERE FROM_USER = 'u' AND FROM_HOST = 'h';，之后再执行 FLUSH PRIVILEGES;（仅在此类手动修复后才需要）
删完用户，数据库对象还在，这正常吗？
正常。DROP USER 只管权限元数据，完全不碰用户创建的库、表、函数、视图等对象。比如用户 'app'@'%' 建了库 app_data，删用户后该库和其中所有表都原样保留。
若需一并清理：
- 先确认归属：
SELECT SCHEMA_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'app_data'; - 再删库：
DROP DATABASE IF EXISTS app_data; - 注意：若其他账号仍有对该库的权限（如
GRANT SELECT ON app_data.* TO 'reporter'@'%'），删库后这些权限会变成ON non_existent_db.*，虽不报错但建议同步清理
真正容易被忽略的是：删用户后，应用连接池里的长连接不会断开，旧权限在会话生命周期内持续有效——必须配合应用侧重启或 KILL 连接才能彻底阻断。
