MySQL中DROP USER与DELETE FROM mysql.user的区别及风险

核心区别解析

DROP USER 命令由 MySQL 服务器内部逻辑处理，能够递归地查找并移除与该用户主机名（Host）匹配的所有权限记录。这是一种“干净”的删除操作。而 DELETE FROM mysql.user 只是对系统表的普通数据修改，它不会触发权限表的级联删除机制。因此，两者的本质区别在于是否保持了权限数据的一致性。

实操演示：权限残留现象

为了直观理解这一差异，我们可以通过一个实验来观察 DELETE 操作后留下的隐藏痕迹。以下操作基于 MySQL 8.0 及以上版本（注意：5.7.6版本后部分字段结构已简化，但原理一致）。

第1步：创建并授权测试用户

首先，我们创建一个名为 'test'@'%'' 的用户，并给予 test 数据库的全部权限，用于模拟遗留环境。

CREATE DATABASE IF NOT EXISTS test;
GRANT ALL ON test.* TO 'test'@'%' IDENTIFIED BY 'test';
FLUSH PRIVILEGES;

第2步：执行非标准删除（DELETE）

进入 mysql 数据库，直接通过 SQL 语句删除该用户的身份信息记录。

USE mysql;
DELETE FROM user WHERE User = 'test' AND Host = '%';
-- 注意：这里没有使用 DROP USER，也没有刷新缓存

第3步：检查权限表残留

虽然 user 表里看不到 test 了，但我们查看 db 表（存储数据库级别权限）：

关键发现：上表显示，即使从 user 表删掉了该用户，db 表中依然保留了 test 用户对 test 库的完全控制权。

第4步：重建同命用户后的连锁反应

此时，如果我们不小心再次创建一个同样名为 'test'@'%'' 的用户，或者系统中有其他进程尝试以该名称连接并授权：

CREATE USER 'test'@'%' IDENTIFIED BY 'new_password';
GRANT SELECT ON test.* TO 'test'@'%';

由于之前的 DELETE 导致权限表状态错乱，新的 test 用户可能会叠加这些残留的权限位。更重要的是，如果存在未清理的旧权限条目，可能导致新用户的实际权限远超预期。正确的做法是重新加载权限表或使用标准的 DROP 命令来避免这种“幽灵权限”。

正确删除用户的完整步骤

为了避免权限碎片化和安全风险，请按照以下步骤操作：

1. 使用标准命令：直接在命令行或客户端执行 DROP USER 'username'@'host';。这比手动写 DELETE 更安全。
2. 刷新缓存：执行 FLUSH PRIVILEGES;，确保内存中的权限副本被更新为最新状态。
3. 验证结果：查询 SELECT * FROM mysql.db WHERE User = 'username'; 确认无多余行；查询 SHOW GRANTS FOR 'username'@'host'; 确认无输出（报错即代表用户不存在）。

排错与注意事项

如果你已经错误地使用了 DELETE FROM user 进行操作，请务必执行以下补救措施：
1. 清理所有权限表：
你需要手动检查并删除 mysql 库下的 db, tables_priv, columns_priv, procs_priv 等表中对应的 User 列记录。
2. 重启服务或刷权：
必须执行 FLUSH PRIVILEGES;，否则 MySQL 进程仍可能在内存中持有旧的权限哈希表，导致行为不可控。
3. 检查当前会话：
确保没有正在运行的脚本或应用仍然使用该账户连接数据库。

总之，DROP USER 是管理数据库用户身份的首选工具。任何涉及 mysql 系统表直接增删改查的操作都应当极其谨慎，因为这绕过了 MySQL 自身的完整性保护层，极易引发权限管理的混乱。