set role none仅对当前会话生效，不改变默认角色配置；彻底禁用需revoke绑定并set default role none；activate_all_roles_on_login=on时角色自动激活；连接池中须通过jdbc参数sessionvariables=default_role=none确保每次新建连接干净初始化。
SET ROLE NONE 只影响当前会话，不是全局禁用
执行 SET ROLE NONE 后，当前连接中该角色的权限立即失效，但其他已建立的连接、新连接或后台任务不受影响。它不修改角色绑定关系，也不改变用户默认角色配置。如果你希望所有会话都“看不到”这个角色，必须配合 SET DEFAULT ROLE NONE TO 'user'@'host'，否则下次登录仍会激活默认角色。
禁用默认角色需显式重置，不能只靠 REVOKE 绑定
仅执行 REVOKE 'role_name' FROM 'user'@'host' 不等于禁用——它只是断开绑定，但若用户此前已设过默认角色（SET DEFAULT ROLE 'role_name' TO ...），那该设置依然存在，且新连接仍会自动启用该角色（除非 activate_all_roles_on_login 为 OFF 且未指定默认角色）。真正禁用的完整操作是：
- 先解绑：
REVOKE 'role_name' FROM 'user'@'host' - 再清除默认角色设定：
SET DEFAULT ROLE NONE TO 'user'@'host' - 最后检查是否生效：登录后执行
SELECT CURRENT_ROLE()，应返回NULL或NONE
角色权限残留常因 activate_all_roles_on_login 配置被忽略
MySQL 默认 activate_all_roles_on_login = OFF，所以角色不会自动激活；但一旦你或运维脚本把它设为 ON，所有绑定角色就会在每次登录时自动启用，SET DEFAULT ROLE 就失去控制力。排查时务必查这个变量：
SELECT @@activate_all_roles_on_login;
如果返回 ON，而你又没做显式 SET ROLE NONE，那角色权限就在后台静默生效。临时禁用最稳妥的方式，是在应用连接初始化 SQL 中强制加一句 SET ROLE NONE，而不是依赖服务端配置。
连接池场景下，SET ROLE NONE 完全无效
像 HikariCP、Druid 这类连接池复用物理连接，SET ROLE NONE 只对当次会话有效，连接归还池后，下次取出时权限状态仍是上次结束时的样子。这意味着你手动执行了禁用，但应用后续请求仍可能走旧连接、带着旧角色权限执行。解决办法只有两个：
- 让连接池配置
connection-init-sql="SET ROLE NONE"（部分驱动支持） - 或者更可靠的做法：改用
sessionVariables=default_role=NONE作为 JDBC URL 参数，确保每次新建连接都从干净状态开始
角色的“临时禁用”本质是会话级控制，脱离连接生命周期谈禁用，基本等于没禁。
