必须用 DROP USER 删除 MySQL 账号，DELETE FROM mysql.user 会因权限缓存导致账号“逻辑残留”；DROP USER 自动清理所有关联权限表，并支持多账号、IF EXISTS 和角色回收前检查。
MySQL 删除账号必须用 DROP USER，DELETE FROM mysql.user 会留后患
直接删 mysql.user 表记录看似快，但 MySQL 8.0+ 会缓存权限、跳过验证逻辑，导致账号“删了还在”——比如仍能连上（空密码或 host 匹配宽松时），或后续 FLUSH PRIVILEGES 失败。真正安全删除只能走 DROP USER。
-
DROP USER自动清理mysql.user、mysql.db、mysql.tables_priv等所有关联权限表 - MySQL 5.7 起支持一次删多个账号：
DROP USER 'u1'@'localhost', 'u2'@'%'; - 如果账号不存在，MySQL 8.0 默认报错；加
IF EXISTS可静默跳过：DROP USER IF EXISTS 'olduser'@'192.168.%';
DROP USER 执行前必须确认账号没在连接中
正在活跃连接的账号执行 DROP USER 不会中断当前会话，但下次认证就会失败。更麻烦的是：如果该账号被其他账号通过 PROXY 权限代理（GRANT PROXY ON 'target'@'%' TO 'proxy'@'%'），删掉 target 账号会导致 proxy 登录直接报 Access denied，且错误信息不提示原因。
- 查活跃连接：
SELECT ID, USER, HOST, COMMAND, TIME FROM information_schema.PROCESSLIST WHERE USER = 'olduser'; - 强制断开（如需）：
KILL 1234;（ID 替换为上一步查到的值） - 检查代理关系：
SELECT * FROM mysql.proxies_priv WHERE CONCAT(User, '@', Host) = 'olduser@%';
MySQL 8.0+ 的角色（ROLE）让账号清理更复杂
如果旧账号被赋予了角色（GRANT role1 TO 'olduser'@'%'），删账号本身没问题，但角色不会自动回收。若之后新建同名账号，可能意外继承原角色权限——尤其当角色含 WITH ADMIN OPTION 时风险更高。
- 删账号前先查它拥有的角色：
SELECT FROM_USER, TO_USER, WITH_ADMIN_OPTION FROM mysql.role_edges WHERE FROM_USER = 'olduser'; - 若需彻底清理，建议先
REVOKE角色：REVOKE role1 FROM 'olduser'@'%';，再DROP USER - 注意：MySQL 8.0.16+ 支持
DROP ROLE IF EXISTS role1;，但角色删除不影响已授权用户的会话权限，只影响新登录
删完账号后别忘了 FLUSH PRIVILEGES？其实不用
DROP USER 是 DDL 操作，MySQL 内部会自动重载权限缓存，无需手动 FLUSH PRIVILEGES。强行执行反而可能触发锁表或权限校验异常（尤其高并发环境）。唯一需要 FLUSH 的场景是：你绕过 DROP USER 直接改了系统表（不该这么做）。
- 验证是否真删干净：
SELECT User, Host FROM mysql.user WHERE User = 'olduser';—— 应返回空集 - 检查权限是否同步清除：
SHOW GRANTS FOR 'olduser'@'%';—— 应报错ERROR 1141 (42000): There is no such grant defined for user 'olduser' on host '%' - 如果使用了 PAM 或 LDAP 认证插件，
DROP USER只删 MySQL 元数据，外部认证源需另行清理
实际操作中最容易漏掉的是代理权限和角色继承，这两处不查不 revoke，就等于把权限“寄存”在系统里等下一个同名账号唤醒。
