DROP USER才是安全删用户的唯一方式，因DELETE FROM mysql.user仅删主表而遗留mysql.db等权限表记录，且MySQL 8.0+权限缓存不一致会导致删后仍可登录、重建同名用户报错等故障。
DROP USER 是唯一安全的删除方式，直接 DELETE mysql.user 会留后患
为什么不能用 DELETE FROM mysql.user
直接删表只会动 mysql.user，其他权限表如 mysql.db、mysql.tables_priv、mysql.proxies_priv 里的记录全还在。MySQL 8.0+ 还有内存级权限缓存，删表后不 FLUSH PRIVILEGES 就连不上；即使 flush 了，也可能触发 ERROR 1396 (HY000): Operation CREATE USER failed for 'xxx'@'%' 这类诡异报错——系统认为用户“还存在”，但查 mysql.user 又找不到。
常见错误现象包括：
- 删完还能用同名账号连上（尤其当 host 匹配宽松或密码为空时）
- 重建同名用户时报错，提示已存在却查不到
-
FLUSH PRIVILEGES自身失败，提示锁表或权限校验异常
用 DROP USER 删除时必须写全用户名@主机名
MySQL 用户由 User 和 Host 共同唯一标识。'alice'@'localhost' 和 'alice'@'%' 是两个完全不同的账号，漏删任意一个都可能造成残留权限。
操作前务必确认完整名称：
- 执行
SELECT User, Host FROM mysql.user;查所有用户 - 注意大小写：用户名区分大小写，主机名不区分
- 特殊字符（如下划线、连字符）无需转义，但需确保拼写完全一致
- 生产环境建议先运行
SHOW GRANTS FOR 'username'@'host';检查权限范围
DROP USER 实际清理哪些内容
DROP USER 是 DDL 操作，MySQL 内部会自动同步清理全部权限相关表，不只是 mysql.user：
-
mysql.user：主账号记录 -
mysql.db：库级权限（如GRANT SELECT ON test.* TO 'u'@'%'） -
mysql.tables_priv：表级权限 -
mysql.columns_priv：字段级权限 -
mysql.proxies_priv：代理关系（PROXY 权限）
它还会自动断开该用户的活跃连接（MySQL 5.7+），且无需手动 FLUSH PRIVILEGES。但已有连接不会立刻失效——权限只对新连接生效，老连接仍维持旧权限直到断开。
误删或需要立即阻断连接怎么办
DROP USER 不可逆，MySQL 没有回收站机制。误删后无法恢复，只能靠备份还原。
若需立即切断用户活动会话：
- 查出该用户所有连接：
SELECT CONCAT('KILL ',id,';') FROM information_schema.processlist WHERE user='olduser'; - 复制结果并执行生成的
KILL语句 - 或者直接批量杀：
KILL <code>id;（注意不是KILL CONNECTION，后者在旧版本不支持）
特别提醒：删除用户不会移除其创建的数据库、表、存储过程等对象，这些必须单独处理。最容易被忽略的是——你删掉的是账号，不是数据；而残留的数据对象，可能成为后续权限混乱的源头。
