mysql 8.0中drop role失败是因为角色被活跃会话占用，需先通过role_edges和processlist查出授权用户及对应活跃会话id，再用kill精确终止，等待会话断开后方可删除。
MySQL 8.0中角色被会话占用时无法直接DROP ROLE
直接执行 DROP ROLE 'role_name' 会报错 ERROR 3715 (HY000): Cannot drop role 'role_name' because it is assigned to one or more users 或更隐蔽的错误：即使没显式授权，只要当前有活跃会话正在使用该角色（比如通过 SET ROLE 激活过），MySQL 8.0 就会拒绝删除。这不是权限问题，而是内部状态锁机制导致的。
必须先查清哪些会话正在使用该角色
MySQL 不提供直接列出“谁在用哪个角色”的视图，得靠组合查询推断。核心思路是：找出所有已激活该角色的连接，并确认其 ROLE_REPLICATION_APPLIER 状态或 CURRENT_ROLE() 值（但后者只能查当前会话）。实际可行方法如下：
- 查
performance_schema.threads中所有非后台线程的PROCESSLIST_INFO，看是否含SET ROLE相关语句（不完全可靠） - 更稳妥的是查
information_schema.role_edges确认哪些用户被授予了该角色，再结合performance_schema.threads的USER字段匹配活跃连接 - 执行
SELECT user, host FROM mysql.role_edges WHERE role_name = 'your_role';得到授权用户列表 - 再运行
SELECT id, user, host, command, time FROM information_schema.processlist WHERE user IN ('user1', 'user2') AND command != 'Sleep';找出这些用户的活跃会话
终止占用会话后再删角色
找到活跃会话后，不能只靠 KILL 用户名——必须用 id 精确终止。注意：KILL 操作本身不会立即释放角色绑定，需等待会话真正断开（通常几秒内）。操作顺序必须严格：
- 记录下所有匹配会话的
ID（来自information_schema.processlist） - 逐个执行
KILL 123;（123是会话 ID） - 等待 2–3 秒，再查一遍
processlist确认对应 ID 已消失 - 此时才能安全执行
DROP ROLE 'your_role'; - 如果角色还被其他用户隐式继承（比如通过
WITH ADMIN OPTION授予并再次转授），需递归检查role_edges的TO_HOST和FROM_HOST字段
避免下次再卡住：角色管理要带清理意识
MySQL 8.0 的角色不是静态配置，它和会话生命周期强绑定。日常运维中容易忽略这点：
- 应用层使用
SET ROLE后，最好显式执行SET ROLE NONE;再退出，否则连接池复用时可能残留角色状态 - 不要依赖“用户没登录就安全”，连接池、监控工具、定时任务脚本都可能悄悄建立连接并激活角色
-
DROP ROLE前养成习惯：先跑一遍SELECT COUNT(*) FROM performance_schema.threads t JOIN information_schema.role_edges r ON t.USER = r.USER WHERE r.role_name = 'xxx';，结果 > 0 就别硬删
角色删除失败往往不是语法或权限问题，而是你没意识到某个后台进程正拿着它干活。盯住 processlist 和 role_edges 这两张表，比反复试错快得多。
