mysql无法删除正在连接的用户是因为其5.7+版本强制校验活跃连接，只要information_schema.processlist中存在目标user记录，drop user即报error 3729；它不中断现有连接，仅清理权限表，需先kill对应id连接才能成功执行。
执行 DROP USER 时提示 “Cannot drop user because they are still connected”
这不是权限问题，也不是锁表或事务阻塞，而是 MySQL 5.7+ 的硬性校验机制：只要目标用户有活跃连接（SHOW PROCESSLIST 中存在对应 USER 字段），DROP USER 就会直接报错 ERROR 3729 (HY000)。它不关心你是不是 root，只检查连接是否存在。
常见误判是以为“当前登录用户不能删自己”，其实更普遍的情况是：你用 root 登录，但另一个应用正以 'appuser'@'192.168.1.10' 连着，这时删 'appuser'@'192.168.1.10' 就会失败。
- 查连接必须带完整匹配：
SELECT ID, USER, HOST FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'appuser' AND HOST LIKE '192.168.1.%';（HOST不支持模糊通配符，LIKE是唯一办法） -
KILL必须用数字 ID，不是用户名：KILL 12345;，不是KILL 'appuser' - MySQL 8.0.13+ 支持
KILL USER 'appuser'@'192.168.1.10'，但不支持'appuser'@'%'这类通配写法，host 必须精确
为什么 DROP USER 不自动断开连接？
MySQL 的设计哲学是“权限变更不影响已有会话”。DROP USER 只清理授权表（mysql.user、mysql.db 等），不干预 TCP 连接层。已建立的连接仍持有旧权限，能继续查询、写入，甚至锁表——直到客户端主动断开或超时。
这导致两个典型现象：
- 删完立刻
SELECT User, Host FROM mysql.user查不到用户，但SHOW PROCESSLIST里还有一堆appuser连接 - 新建同名用户后，旧连接仍按老权限运行，新连接才走新权限，造成行为不一致
所以不能跳过 KILL 直接 DROP USER，否则等于“删了门牌，但屋里人还在住”。
主机名（Host）匹配错误导致删不掉
MySQL 用户是 'user'@'host' 二元组，'user'@'localhost' 和 'user'@'127.0.0.1' 完全是两个账户。漏掉 host 或写错格式，DROP USER 就像在找一个不存在的人。
排查要点：
- 先查全量：
SELECT User, Host FROM mysql.user WHERE User = 'appuser';—— 注意大小写，User区分大小写，Host不区分 - 连接来源可能被解析为域名：
'appuser'@'web01.internal.example.com'，不是'appuser'@'%' - 代理或 NAT 场景下，
HOST可能是内网 IP，比如'appuser'@'10.0.2.5'，而非你预设的'appuser'@'192.168.%'
删之前务必确认 host 字段和 PROCESSLIST 中显示的一致，否则删了 A 却留着 B。
误用 DELETE FROM mysql.user 的后果
直接删系统表是高危操作。它只动 mysql.user，但不会清理 mysql.db、mysql.tables_priv、mysql.proxies_priv 里的残留记录，结果就是权限状态错乱。
典型症状包括：
- 删完再建同名用户，
SHOW GRANTS显示一堆不该有的权限 - 用户重建后仍能访问原数据库，因为
mysql.db表没清 - MySQL 8.0+ 中手动删字段可能触发内部校验失败，服务异常
永远优先用 DROP USER；只有在极少数旧版本兼容场景（如 MySQL 5.6 删除空用户名）才考虑 DELETE + FLUSH PRIVILEGES，且必须同步清理所有关联表。
HOST 值、没杀干净连接、或者以为删完就万事大吉——旧连接还在跑着，权限缓存还没刷新，而新用户已经顶上去了。
