必须用drop user而非delete from mysql.user，因后者仅删user表，残留db、tables_priv等权限记录及内存缓存不一致，易致重连成功、create user报错1396等故障。
为什么不能用 DELETE FROM mysql.user 直接删账号
直接执行 DELETE FROM mysql.user WHERE User = 'xxx' AND Host = 'localhost' 看似快，但只动了这一张表。MySQL 的权限系统是多表联动的：mysql.db、mysql.tables_priv、mysql.proxies_priv 里残留的记录全还在。更麻烦的是，MySQL 8.0+ 会把权限缓存在内存里，删表后不 FLUSH PRIVILEGES 就连不上；即使 flush 了，也可能因状态不一致导致后续 CREATE USER 报错 ERROR 1396 (HY000): Operation CREATE USER failed for 'xxx'@'%'。
常见错误现象包括：
- 删完用户，用同名账号重连仍成功（尤其当 host 匹配宽松或密码为空时）
- 重建同名用户时报错，提示“user already exists”却查不到
-
FLUSH PRIVILEGES执行失败，提示锁表或权限校验异常
必须用 DROP USER，且要带 host 精确匹配
DROP USER 是 DDL 操作，MySQL 内部会自动同步清理所有权限相关表，不只是 mysql.user，还包括 mysql.db、mysql.tables_priv、mysql.columns_priv、mysql.proxies_priv。它不依赖 FLUSH PRIVILEGES，删完即生效。
关键点：
- 必须写全
'username'@'host'，比如DROP USER 'api_user'@'10.20.%.%'；只写'api_user'会报语法错误 - MySQL 5.7+ 支持一次删多个：
DROP USER 'u1'@'localhost', 'u2'@'%'; - MySQL 8.0+ 支持
DROP USER IF EXISTS 'u'@'%'，避免因用户不存在报错，但依然完整走权限清理流程
删账号前必须检查三件事
跳过这些检查，大概率卡在权限、连接或角色上：
- 确认当前账号有权限：必须拥有
CREATE USER全局权限，或DELETE ON mysql.*。执行SHOW GRANTS FOR CURRENT_USER查看，没对应权限就别硬试，否则报错ERROR 1227 (42501) - 检查是否有活跃连接：
SELECT ID, USER, HOST FROM information_schema.PROCESSLIST WHERE USER = 'xxx';。如有必要，用KILL 1234（ID 替换为实际值）终止 - 检查是否被赋予角色（MySQL 8.0+）：
SELECT * FROM mysql.role_edges WHERE FROM_USER = 'xxx';。若该用户是某个角色的成员，删账号前需先REVOKE ROLE ... FROM 'xxx'@'...'
如何批量识别并安全清理冗余账号
别靠 SHOW GRANTS 单独查——它不显示 host，而 'user'@'10.%.%.%' 和 'user'@'%' 是两个权限主体。正确做法是：
- 先过滤掉系统账号：
SELECT User, Host FROM mysql.user WHERE User NOT LIKE 'mysql.%' AND User != ''; - 查最近登录行为（需开启
performance_schema）：SELECT user, host, last_seen FROM performance_schema.accounts WHERE user != '' AND last_seen IS NOT NULL ORDER BY last_seen LIMIT 10; - 检查权限是否仅为
USAGE：SELECT * FROM mysql.db WHERE User = 'xxx';，空结果 +SHOW GRANTS FOR 'xxx'@'yyy'返回只有USAGE，才可能是真闲置 - 自动化脚本里务必避开
root@localhost——它的权限可能被隐式继承，误删会导致运维中断
真正安全的清理必须和应用侧协同：先注释掉连接池配置里的账号，重启服务，再确认无活跃连接，最后执行 DROP USER。MySQL 不会主动踢掉已建立的连接，删账号后老连接还能继续跑，直到超时，这期间可能产生脏数据或权限绕过。
