不能只靠REVOKE ALL PRIVILEGES，必须组合执行角色解绑、USAGE撤销、连接清理和DEFINER检查，否则权限“看起来没了”但实际仍生效。
直接结论：不能只靠 REVOKE ALL PRIVILEGES，必须组合执行角色解绑、USAGE 撤销、连接清理和 DEFINDER 检查，否则权限“看起来没了”但实际仍生效。
为什么 REVOKE ALL PRIVILEGES, GRANT OPTION ON *.* FROM 'user'@'host' 不够用
这条语句只清掉用户在 mysql.user 和 mysql.db 表里显式授予的权限，但完全不碰以下三类残留：
- 角色（role）绑定：如果该用户被
GRANT 'analyst_role' TO 'alice'@'10.20.30.%'过，角色里的所有权限（包括后续新增的）继续生效 -
USAGE权限：这是隐式存在的“连接权”，REVOKE ALL不会删它，用户仍能成功登录，只是执行具体操作时报错 - DEFINER 依赖：若该用户是某视图、存储过程或事件的
DEFINER，MySQL 会保留其账户记录以维持对象可执行性，导致DROP USER失败
DROP USER 是最彻底方式，但有三个硬性前提
执行 DROP USER 'alice'@'10.20.30.%' 前必须确认：
- 无活跃连接：查
SELECT ID, USER, HOST, TIME FROM information_schema.PROCESSLIST WHERE USER = 'alice'，存在则先KILL CONNECTION <id></id> - 无 DEFINER 引用：运行
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, DEFINER FROM information_schema.ROUTINES WHERE DEFINER = 'alice@10.20.30.%';，结果非空需先ALTER DEFINER或删对象 - 无中间件硬编码：ProxySQL、MaxScale 或应用配置里写死该用户名，删后报
Unknown user而非权限错误，排查路径变长
权限回收后仍“能操作”？检查这三处真实残留
即使 DROP USER 成功返回，用户可能还在干活，原因不是权限没删干净，而是：
- 客户端未重连：旧连接仍持有完整权限上下文，必须等超时或主动
KILL才失效 - 主机名匹配宽泛：你删的是
'alice'@'10.20.30.%'，但用户实际用'alice'@'10.20.30.123'连——MySQL 视为不同账号，得查SELECT User, Host FROM mysql.user WHERE User = 'alice'确认全量匹配 - 代理用户（proxy user）未处理：若该用户被设为其他用户的
PROXY，需额外执行REVOKE PROXY ON 'target_user'@'%' FROM 'alice'@'10.20.30.%'
真正安全的交接流程：四步不可跳过
离职交接不是单条命令的事，必须按顺序走完：
- 第一步：解绑所有角色 →
REVOKE 'role1', 'role2' FROM 'alice'@'10.20.30.%' - 第二步：显式撤销 USAGE →
REVOKE USAGE ON *.* FROM 'alice'@'10.20.30.%'（这步断开新连接能力） - 第三步：检查并清理 DEFINER/PROXY 依赖 → 查
information_schema相关表，改或删 - 第四步：最后执行
DROP USER，再验证SELECT User, Host FROM mysql.user确认记录消失
复杂点不在命令本身，而在角色继承链、DEFINER 隐式依赖和中间件配置这些容易被忽略的耦合点。漏掉任意一环，都可能让权限在“已回收”状态下继续生效数小时甚至数天。
