在MySQL运维中，删除用户是常见操作，但不少人执行删除命令时遇到各种失败。这些失败通常并不是MySQL本身有缺陷，而是对MySQL的账户模型和权限系统理解不够导致的。只有弄清楚用户是怎么存储的、权限是怎么关联的，才能用正确的方式把账号清掉。
一、为什么MySQL删除用户会失败
MySQL中的用户并不是单靠用户名就能唯一确定的，而是由user和host两部分共同组成，写作'username'@'host'。当你执行DROP USER 'tom';而没有指定host时，MySQL默认按'tom'@'%'去匹配，如果实际账号是'tom'@'localhost'，就会报“Can't find any matching row in the user table”。这就是最常见的删除失败原因。
另外，有些管理员图省事直接用DELETE语句删掉mysql.user表中的记录，例如DELETE FROM mysql.user WHERE user='tom';，随后却没有执行FLUSH PRIVILEGES;。这样内存里的权限缓存不会更新，且关联的库表级权限可能还留在mysql.db等表中，造成元数据不一致，后续新建同名用户或做权限校验时就会出怪问题。
二、标准且安全的删除步骤
在动手之前，先查看当前实例里有哪些用户以及它们的host。可以用如下语句列出全部账户：
SELECT user, host FROM mysql.user;
确认目标账号后，使用带host的DROP USER语句。如果账号在多个host下都存在，要分别删除，或者用一条语句批量写：
-- 删除特定主机的账号 DROP USER 'tom'@'localhost'; -- 一次性删除多个账号 DROP USER 'tom'@'127.0.0.1', 'tom'@'192.168.0.1';
在MySQL 5.7及以上版本，DROP USER会自动回收该用户在各库表上的权限并刷新权限，不需要手动FLUSH。但如果你用的是老版本，或者之前用手工DELETE方式动过表，建议删完后再执行一次FLUSH PRIVILEGES;保证内存与磁盘一致。
三、遇到报错的具体处理办法
如果执行DROP USER时报“ERROR 1396 (HY000): Operation DROP USER failed”，可以先查mysql.user里是否真有这行。有时是大小写或特殊字符导致匹配失败，用引号严格包裹名称通常能解决。还有一类情况是用户正在连接，某些旧版本不允许删正在用的会话账号，需要先杀掉连接：
-- 查看连接 SHOW PROCESSLIST; -- 杀掉指定连接Id KILL 12345; -- 再删除用户 DROP USER 'tom'@'localhost';
若是提示“There are still visible temp tables”，一般出现在中途断连场景，重启客户端或等临时表释放后再删即可。千万不要为了绕开报错直接改mysql系统库，那样容易把grant表弄坏，后续只能用mysql_upgrade修复。
四、用权限回收代替误删的预防方式
在正式删除前，推荐先看一眼这个用户拥有什么权限，避免误删后业务断连找不到原因。通过SHOW GRANTS能列出完整授权：
SHOW GRANTS FOR 'tom'@'localhost';
如果确定不再需要，但想保留账号做审计，也可以只回收权限而保留用户行：
-- 回收所有权限 REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'tom'@'localhost'; -- 如确定废弃再执行删除 DROP USER 'tom'@'localhost';
这种先回收再删除的习惯，能让你在出问题时快速回退授权，也不会因为直接删账号导致应用抛“Access denied”却查不到是谁被删了。
五、总结对比
下面用表格列出几种删除方式的差异，方便选择：
| 方式 | 是否推荐 | 风险点 |
|---|---|---|
| DROP USER带host | 推荐 | 几乎无风险，自动清权限 |
| DELETE改mysql.user | 不推荐 | 权限表不一致，需手动FLUSH |
| 只回收权限不删账号 | 视情况 | 占用user表行，但更安全 |
只要记住MySQL用户是user@host整体，删除时写全，别碰系统表，基本就不会再卡在删除失败上。遇到报错按上述思路查连接、查大小写、查残留权限，都能解决。