删用户不等于断连接，必须先kill再drop user；kill中断活跃会话，drop user仅删元数据；flush privileges对已连会话无效，只影响新连接。
因为连接是独立于用户记录存在的，删用户不等于断连接。 MySQL 的连接生命周期由客户端发起、服务端维持，只要 TCP 连接没被主动关闭或超时，即使你执行了 DROP USER 或 DELETE FROM mysql.user，已建立的会话仍可继续执行语句、读写数据——直到它自己断开、被 kill，或服务重启。
为什么 KILL 命令比 DROP USER 更优先？
用户删除操作只影响权限元数据，不触碰运行时连接。真正要让“已删用户”立刻失去操作能力，必须先终止其活跃连接：
-
KILL是唯一能立即中断指定连接的方式，语法为KILL [CONNECTION] <id></id>或KILL QUERY <id></id> - 需先查出目标用户的连接 ID：
SELECT ID, USER, HOST, COMMAND, TIME FROM information_schema.PROCESSLIST WHERE USER = 'xxx'; - MySQL 8.0+ 中，
KILL默认只终止当前语句（KILL QUERY），加CONNECTION才真正断开整个会话 - 若用
KILL后连接仍存在，说明客户端启用了自动重连（如 JDBC 的autoReconnect=true），此时需配合应用层配置调整
为什么 FLUSH PRIVILEGES 不能解决连接活跃问题？
FLUSH PRIVILEGES 只刷新内存中的权限缓存，不影响已认证会话的权限上下文。一个已登录用户的权限在连接建立时就已确定并固化，后续删用户、改权限、甚至 FLUSH PRIVILEGES 都不会改变该连接当前拥有的权限集。
- 它的作用仅限于：让新连接（或后续新建连接）生效最新权限配置
- 对已有连接完全无效，既不会降权，也不会触发断连
- 在 MySQL 8.0+ 中，
DROP USER已自动触发权限重载，通常无需手动FLUSH PRIVILEGES - 误用
FLUSH PRIVILEGES还可能掩盖真正问题——比如你以为“刷了就安全了”，其实连接还在跑着
用户删除后连接仍活跃的真实场景
常见于长连接池、监控脚本、未正确关闭的 CLI 会话等场景。典型表现是：你刚执行完 DROP USER 'app'@'192.168.1.%'，但 SHOW PROCESSLIST 里还能看到 app 用户的连接，且状态为 Query 或 Sleep。
- 根本原因在于 host 匹配粒度：你删的是
'app'@'192.168.1.%'，但连接可能是通过'app'@'192.168.1.100'建立的——MySQL 认为这是两个不同用户，不会自动关联清理 - 如果用户有 PROXY 权限，
DROP USER不清理mysql.proxies_priv表，代理关系残留可能导致后续连接行为异常 - 应用使用连接池时，即使服务端删了用户，客户端可能仍在复用旧连接，直到连接空闲超时或池主动驱逐
真正要确保“删即断”，必须组合操作：先 KILL 所有匹配连接，再 DROP USER，最后确认无残留连接。漏掉 KILL 这步，等于只撕了门牌，没锁门。
