DELETE FROM mysql.user 不会清理权限，正确做法是使用 DROP USER 命令原子性清除所有关联权限表，并执行 FLUSH PRIVILEGES；残留权限需手动清理 mysql.db 等表并刷新。
DELETE FROM mysql.user 后权限还在？别手删表
直接 DELETE FROM mysql.user 不会清理权限，还会导致 mysql.db、mysql.tables_priv 等表残留记录，下次 CREATE USER 同名时可能继承旧权限。MySQL 的权限系统是多表联动的，不是删一行就完事。
正确做法永远是走 DROP USER，它内部会原子性清理所有关联权限表。如果用户已被手动删表，现在得补救：
- 先查残留：
SELECT * FROM mysql.db WHERE User = 'xxx';、SELECT * FROM mysql.tables_priv WHERE User = 'xxx'; - 逐个清理：
DELETE FROM mysql.db WHERE User = 'xxx';、DELETE FROM mysql.tables_priv WHERE User = 'xxx';（同理检查procs_priv、columns_priv） - 最后必须执行：
FLUSH PRIVILEGES;，否则内存缓存不更新，删了也白删
DROP USER 执行失败：ERROR 1396 (HY000)
常见报错：ERROR 1396 (HY000): Operation DROP USER failed for 'xxx'@'%'。这不是权限问题，而是用户根本不存在——但 MySQL 检查时发现权限表里有残留记录（比如之前手删过 mysql.user），导致状态不一致。
解决路径很窄，只有两条：
- 确认是否存在：
SELECT User, Host FROM mysql.user WHERE User = 'xxx';（注意 Host 可能是'xxx'@'localhost'而非'xxx'@'%'） - 若查不到但删不掉，说明是残留权限记录干扰，按上一节方法清空所有
User = 'xxx'的行，再FLUSH PRIVILEGES - 不要用
DROP USER IF EXISTS掩盖问题——它只是静默跳过，残留仍在
DROP USER 不删数据库？对，这是设计如此
DROP USER 只动权限元数据，完全不碰用户创建的库、表、数据。这是明确的行为边界：权限管理 ≠ 对象生命周期管理。
如果你顺手建了同名数据库（比如 CREATE DATABASE xxx;），它不会被连带删除。需要单独处理：
- 确认归属：
SELECT SCHEMA_NAME, DEFAULT_CHARACTER_SET_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'xxx'; - 手动删库：
DROP DATABASE IF EXISTS xxx; - 注意：如果其他用户还有对该库的权限（比如
GRANT SELECT ON xxx.* TO 'other'@'...';），删库后那些权限就变成悬空的ON non_existent_db.*，虽不影响运行，但建议一并清理
MySQL 5.7 和 8.0 的 DROP USER 行为差异
5.7 默认不自动回收角色权限，8.0+ 改了：如果用户被赋予了角色（GRANT role_name TO 'u'@'h';），DROP USER 会同时解除角色绑定。但角色本身不会被删，除非显式 DROP ROLE。
另一个关键区别在匿名用户处理：
- 5.7 中
DROP USER ''@'localhost'是合法的；8.0 默认禁用匿名用户，且DROP USER对空用户名更严格，容易报错 - 8.0 引入了
password_expired字段和密码历史策略，DROP USER会一并清除这些状态，5.7 没这层逻辑 - 跨版本迁移时，别假设
DROP USER行为一致，尤其涉及角色或密码策略的环境
最常被忽略的一点：DROP USER 不影响当前已建立的连接。那些连接仍以原用户身份运行，直到断开。如果要立刻切断，得配合 KILL 或等连接超时。权限清理和连接生命周期是两件事，别混为一谈。
