DROP USER 不会断开用户连接，必须先KILL再DROP；它只清理权限不终止会话，残留连接可继续操作数据，且DELETE FROM mysql.user危险易致权限混乱。
DROP USER 不会主动断开用户连接
MySQL 的 DROP USER 语句只做权限清理，不会终止任何活跃会话。即使你执行了 DROP USER 'user'@'host'，只要该用户当前还有未关闭的连接，其会话仍能继续运行、执行查询、甚至修改数据——直到连接自然断开或被手动杀掉。
常见错误现象包括：
- 执行
DROP USER后，SELECT User, Host FROM mysql.user看不到该用户，但SHOW PROCESSLIST里仍能看到同名连接 - 误以为用户已“消失”，结果发现它还在写日志、占内存、甚至锁表
- 后续用相同用户名重建用户时，因残留连接持有旧权限，行为异常
所以不能跳过连接清理这步。
如何安全删除：先 KILL，再 DROP
必须分两步操作，顺序不能颠倒：
- 查出目标用户的全部连接：
SELECT ID, USER, HOST, DB, COMMAND, TIME FROM information_schema.PROCESSLIST WHERE USER = 'xxx' AND HOST LIKE '%xxx%'; - 对每个匹配的
ID执行：KILL [ID]（注意不是KILL QUERY [ID]，后者只终止当前语句，连接还活着） - 确认无残留连接后，再执行：
DROP USER 'xxx'@'yyy' - 不需要
FLUSH PRIVILEGES——DROP USER自动生效
如果你用的是 MySQL 5.7+，也可以用 KILL USER 'xxx'@'yyy' 一键杀光该账号所有连接（但注意：该语法不支持通配符，必须写全 host）。
为什么不用 DELETE FROM mysql.user？
直接删 mysql.user 表是危险操作，原因很实在：
-
DELETE FROM mysql.user WHERE User='xxx' AND Host='localhost'只删 user 表，不碰mysql.db、mysql.tables_priv等权限表，残留权限可能引发冲突 - 删完必须立刻
FLUSH PRIVILEGES，否则新创建同名用户时可能报错 “User already exists” 或权限混乱 - MySQL 8.0+ 中
mysql.user表结构有变更，手动删字段容易出错 -
DROP USER是原子操作，语义清晰、兼容性好，且自动清理所有相关权限记录
除非你明确在调试权限表结构，否则别碰 DELETE FROM mysql.user。
容易被忽略的细节
真正容易翻车的地方往往藏在 host 匹配和权限残留上：
- 用户可能是
'user'@'192.168.1.%'或'user'@'%.example.com'，用DROP USER 'user'默认只删'user'@'%'，其他 host 实例还在 - 如果用户有
PROXY权限，DROP USER不会自动清理mysql.proxies_priv表中的对应行（需手动删或用DROP PROXY） - 删除后立即用同名用户重连，若客户端复用旧连接池，可能短暂看到 “Access denied”，因为服务端已删用户，但客户端还没重建连接
- MySQL 8.0.16+ 支持
DROP USER IF EXISTS，但依然不解决连接问题——它只是避免报错，不替代KILL
最稳妥的做法永远是：先 SHOW PROCESSLIST 确认连接，再 KILL，最后 DROP USER。别图省事跳步骤。
