直接delete from mysql.user会导致权限系统不一致，因mysql不会自动清理mysql.db等关联表中的对应记录，产生悬空权限；且不刷新权限缓存，已连接会话仍可凭旧权限操作，存在绕过风险。
为什么不能直接 DELETE FROM mysql.user
直接删 mysql.user 行会导致权限系统不一致：MySQL 不会自动同步清理 mysql.db、mysql.tables_priv、mysql.procs_priv 等关联权限表里的对应记录。残留的权限行可能指向已不存在的用户，形成悬空权限（如 ON non_existent_db.*），虽不报错但干扰审计、误判权限范围，甚至在某些插件或代理层引发未预期行为。
更危险的是，DELETE 不触发权限缓存刷新，已建立的连接仍能凭旧权限继续操作，直到下次认证或服务重启——这期间存在权限绕过风险。
DROP USER 才是正确入口，但得配 FLUSH PRIVILEGES 吗？
MySQL 5.7+ 和 8.0+ 的 DROP USER 'u'@'h' 本身会自动清理所有相关权限表记录，并重置内存权限缓存，**不需要手动执行 FLUSH PRIVILEGES**。强行加这个命令不仅多余，还可能在高并发场景下引发短暂权限检查延迟（因缓存重建开销）。
唯一需要 FLUSH PRIVILEGES 的情况是：你绕过正规流程，用 INSERT/UPDATE/DELETE 直接改了权限表——但这属于高危操作，应避免。
- 确认用户是否真被删干净：
SELECT User, Host FROM mysql.user WHERE User = 'xxx' AND Host = 'yyy';应无返回 - 检查残留权限：
SELECT * FROM mysql.db WHERE User = 'xxx' AND Host = 'yyy';同样应为空 - 若发现非空结果，说明之前用了
DELETE而非DROP USER，此时必须补救：先DROP USER 'xxx'@'yyy'（MySQL 8.0+ 会自动覆盖修复），再验证
MySQL 8.0+ 特别注意：角色绑定残留比权限表更隐蔽
8.0 引入角色后，一个用户可能没直授任何权限，却通过 GRANT role_name TO 'u'@'h' 继承全部能力。删用户时 DROP USER 虽会解绑角色，但 mysql.role_edges 表里若存在孤立边（如 FROM_USER 已删，TO_USER 还在），就构成逻辑脏数据。
查这类残留：SELECT * FROM mysql.role_edges WHERE FROM_USER = 'xxx' AND FROM_HOST = 'yyy';
真正安全的清理节奏是：
- 先停应用侧连接池，确保无新连接建立
- 用
SELECT ID, USER, HOST FROM information_schema.PROCESSLIST WHERE USER = 'xxx'确认无活跃会话 - 执行
DROP USER 'xxx'@'yyy' - 最后查
mysql.role_edges和mysql.db验证是否清零
删完用户，但 mysql.db 里还有库级权限残留怎么办
极少数情况下（比如早期 5.7 升级到 8.0 未彻底初始化），DROP USER 可能漏掉 mysql.db 中以 ''（空字符串）为 Host 的旧式匹配行。这种行不会被常规查询捕获，因为 WHERE Host = 'yyy' 匹配不到空值。
查法：SELECT User, Host, Db FROM mysql.db WHERE User = 'xxx' AND (Host = 'yyy' OR Host = '')
清理它必须用 DROP USER 补刀，而非 DELETE —— 因为只有 DROP USER 会触发全路径权限回收逻辑。如果该用户已不存在，先建个临时同名用户再删：CREATE USER 'xxx'@'localhost' IDENTIFIED WITH mysql_native_password BY 'x'; DROP USER 'xxx'@'localhost';
这类空 Host 残留常出现在老版本迁移后，不显式处理，会在权限审计时反复出现“用户不存在但有库权限”的矛盾报告。
