必须用 DROP USER 而非 DELETE FROM mysql.user，因后者仅删主表、留孤儿权限记录，导致缓存错乱、CREATE USER 失败；DROP USER 才能原子清理 user、db、tables_priv 等全部关联表。
直接删 mysql.user 表里的记录是危险操作，会导致权限表不一致、缓存错乱，甚至后续 CREATE USER 失败；必须用 DROP USER，它才是唯一能原子清理所有权限表的合法方式。
为什么不能 DELETE FROM mysql.user
MySQL 的权限体系跨多张表：除了 mysql.user，还有 mysql.db、mysql.tables_priv、mysql.proxies_priv、mysql.role_edges（8.0+）等。手动删 user 表只动了一张，其他表里残留的权限行会变成“孤儿记录”。后果包括：
- 执行
FLUSH PRIVILEGES后，部分旧权限仍生效（因为mysql.db里还存着） - 再创建同名用户时可能报
ERROR 1396 (HY000): Operation CREATE USER failed for 'xxx'@'%'——系统认为该账号“逻辑上还存在”，但查mysql.user又找不到 - MySQL 8.0+ 有内存级权限缓存，删表后即使 flush 也未必同步，连接可能卡在认证阶段
DROP USER 能清哪些、不能清哪些
DROP USER 'u'@'h' 是 DDL 操作，MySQL 内部会自动同步清理以下所有关联表：
-
mysql.user（主账号） -
mysql.db、mysql.tables_priv、mysql.columns_priv、mysql.procs_priv -
mysql.proxies_priv（代理关系） -
mysql.role_edges中以该用户为FROM_USER的行（8.0.16+ 自动解除绑定）
但它不会：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 中断已建立的连接——老连接仍持旧权限运行，直到断开
- 删除角色本身（如果用户被授过角色，角色还在，只是解绑）
- 清理外部系统中硬编码的用户名，比如 ProxySQL 的
mysql_users表、JDBC URL、主从复制的SOURCE_USER
删之前必须查清三类残留源头
一个账号是否真“该删”，不能只看 SHOW GRANTS。要交叉验证：
-
连接活跃度：查
performance_schema.accounts（需先启用：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'accounts';），过滤LAST_SEEN 且非系统账号 -
代理依赖：运行
SELECT * FROM mysql.proxies_priv WHERE CONCAT(User, '@', Host) = 'u@h';，若结果非空，说明其他账号靠它代理登录，删了会静默失败 -
角色继承链：查
SELECT FROM_USER, TO_USER FROM mysql.role_edges WHERE TO_USER = 'u' AND TO_HOST = 'h';，确认是否有其他用户通过角色间接获得该账号权限
删完还要手动收尾的三个地方
DROP USER 执行完，不代表万事大吉。这几处必须人工核对：
-
活跃连接：用
SELECT ID, USER, HOST FROM information_schema.PROCESSLIST WHERE USER = 'u';，有结果就得KILL 1234;（不是KILL CONNECTION） -
锁定但未删的半死账号：执行
SELECT User, Host FROM mysql.user WHERE account_locked = 'Y' AND Select_priv = 'N' AND authentication_string REGEXP '^\*0$|^\*1$|^$';，这类账号得单独DROP USER -
外部配置残留：检查应用配置（如 Spring Boot 的
spring.datasource.username）、ProxySQL、Ansible 变量、备份脚本里的硬编码用户名——它们不会随DROP USER自动失效
最易被忽略的是：删用户不等于删连接，也不等于删代理和角色依赖；而 DELETE FROM mysql.user 看似快，实则埋雷，一次误操作可能让后续两周都在排查权限异常。
