执行 DROP USER 前须确认并终止用户活跃连接，否则报错；该操作级联删除权限但不删数据库对象，MySQL 5.7 与 8.0 在角色清理上存在差异，同名账号可复用但需注意连接残留和权限缓存。
执行 DROP USER 前必须确认用户是否还在连接中
MySQL 不会自动中断用户的活跃连接，直接运行 DROP USER 'u1'@'localhost' 会报错：ERROR 3729 (HY000): Cannot drop user 'u1'@'localhost' because they are still connected。这不是权限问题，而是连接未释放的硬性限制。
- 先查活跃连接：
SELECT ID, USER, HOST, COMMAND, TIME FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'u1';</li> <li>有结果就用 <code>KILL <code>ID
逐个终止（注意：ID 是数字，不是字符串） - 如果用户用的是代理或连接池，可能有短时重连，建议在低峰期操作
DROP USER 会级联删除权限但不删数据库对象
这个指令本质是清理 mysql.user 表和相关授权表（mysql.db、mysql.tables_priv 等），但它完全不影响该用户创建的数据库、表、存储过程等——这些仍属于 DEFINER 或 OWNER，但失去访问入口后变成“孤儿对象”。
- 若用户建过库（比如
CREATE DATABASE u1_app），删用户后库还在，只是没人能进（除非其他用户有权限） - 想一并清理数据，得手动
DROP DATABASE u1_app，且需确保没其他用户依赖它 -
DROP USER不支持IF EXISTS（MySQL 8.0.12+ 才支持），老版本要先查再删，否则报错中断脚本
MySQL 5.7 和 8.0 的 DROP USER 行为差异
主要区别在默认行为和账户清理粒度。MySQL 5.7 只删 mysql.user 行；8.0 默认同时清空角色关联、密码历史、甚至 mysql.role_edges 中的记录。
- 5.7 下，如果用户被赋予了角色，
DROP USER不动角色本身，也不清mysql.role_edges，残留记录可能导致后续角色管理异常 - 8.0 下，
DROP USER会自动解除所有角色绑定，但不会删角色定义——角色本身还得用DROP ROLE - 两者都不动
mysql.procs_priv中的存储过程权限，这类权限得单独处理
用 DROP USER 删除用户后，账号名还能被立即复用吗？
可以，但要注意权限缓存延迟。MySQL 授权表变更后，新连接立刻生效，但已建立的连接仍维持旧权限，直到断开。
- 删完马上
CREATE USER 'u1'@'localhost'不会冲突 - 但如果刚删的用户还有活跃连接，新同名用户无法登录，因为连接池或客户端可能还在重试旧凭据，报
Access denied - 安全起见，删完建议执行
FLUSH PRIVILEGES（虽然通常不需要，但可强制刷新权限缓存）
