必须用 DROP USER 删除用户，因其原子性清理所有权限表；手动删表或仅回收权限会残留记录、引发错误或权限继续生效。
直接用 DROP USER 是唯一安全方式，其他操作（比如 DELETE FROM mysql.user 或只 REVOKE）都会留下权限残留、连接缓存或系统状态不一致问题。
必须用 DROP USER，不能手删 mysql.user
MySQL 的权限不是只存在 mysql.user 一张表里：mysql.db、mysql.tables_priv、mysql.proxies_priv、mysql.role_edges 等都可能存有该用户的记录。手动删表只会让这些残留条目继续生效，甚至导致后续 CREATE USER 报错 ERROR 1396 (HY000)——系统认为用户“还存在”，但查 mysql.user 又找不到。
-
DROP USER是 DDL 操作，MySQL 内部会原子性清理所有权限相关表，无需FLUSH PRIVILEGES - MySQL 8.0+ 支持
DROP USER IF EXISTS 'u'@'%'，避免因用户不存在报错，但清理逻辑不变 - 5.7 起支持一次删多个账号：
DROP USER 'u1'@'localhost', 'u2'@'%';
删之前必须确认三件事：用户名全匹配、活跃连接、角色绑定
漏掉任意一项，就可能删不干净或引发应用异常。
- 用户名和主机名是联合主键，
'app'@'localhost'和'app'@'%'是两个独立账号。执行前先查：SELECT User, Host FROM mysql.user WHERE User = 'app'; - 已有连接不会自动断开。查活连接：
SELECT ID, USER, HOST FROM information_schema.PROCESSLIST WHERE USER = 'app';，必要时手动KILL 1234;（不是KILL CONNECTION） - MySQL 8.0+ 用户可能绑定了角色。查绑定关系：
SELECT FROM_USER, TO_USER FROM mysql.role_edges WHERE TO_USER = 'app';，删用户前建议先REVOKE 'role_name' FROM 'app'@'%';，避免角色残留影响审计或误授
删完仍能连？那是连接缓存旧权限
DROP USER 不会中断当前会话。已建立的连接仍以旧权限运行，直到断开重连。这意味着你执行完命令、查 mysql.user 确认为空、甚至 SHOW GRANTS FOR 'app'@'%' 报错“用户不存在”，但正在跑的应用依然能执行 DROP TABLE ——只要它连着没断。
- 这不是 bug，是 MySQL 的设计行为（官方文档明确说明：“the statement does not take effect until that user's session is closed”）
- 如果需立即阻断，只能主动
KILL对应连接，或等应用自然重连 - 别指望
FLUSH PRIVILEGES能刷新这个状态，它对已存在的连接无效
别忘了外部配置里的硬编码用户名
DROP USER 只动数据库内权限系统，不影响任何外部配置。JDBC URL、ProxySQL 的 mysql_users 表、主从复制的 SOURCE_USER、甚至 shell 脚本里的 -u app，这些都不会自动失效。
- 删用户前，务必搜索所有业务配置、CI/CD 流水线、监控脚本、备份任务中是否引用了该账号
- 尤其注意通配符账号（如
'app'@'192.168.%'）是否被更宽泛的规则（如'app'@'%'）覆盖，避免误删后服务静默降级 - 删完后建议在测试环境模拟重连，验证所有依赖路径是否真正断开
最常被跳过的其实是连接残留和外部配置这两块——它们不报错，但会让“已删除”的用户在某个凌晨三点突然执行了一条 TRUNCATE。
