直接执行 REVOKE 'role_name' FROM 'user'@'host' 即可安全解绑角色，无需查角色内容或逐条撤权限；解绑只断开关联，不修改角色定义，且需确保用户名和主机名与授权时完全一致。
如何从用户身上解绑某个角色
直接执行 REVOKE 'role_name' FROM 'user'@'host' 即可解除绑定，这是唯一安全、标准的做法。MySQL 不会自动清理角色内嵌的权限，也不会影响该用户已有的其他显式授权（比如直接授予的 SELECT ON app.*）或其它角色。
常见错误是误以为要先查角色内容再逐条撤权限——完全没必要。角色只是容器，解绑动作本身不修改角色定义，只断开用户与它的关联。
- 必须确保
role_name和'user'@'host'与当初GRANT 'role_name' TO ...时完全一致，主机名不匹配会报ERROR 3530 (HY000): Cannot revoke role 'xxx' from user 'yyy'@'zzz' - 若用户当前正激活该角色（如执行过
SET ROLE 'role_name'），解绑后需重新SET ROLE NONE或重连才能看到权限变化 - 解绑后，
SHOW GRANTS FOR 'user'@'host'输出里将不再出现该角色名；但若还绑着别的角色，那些仍会显示
为什么不能用 REVOKE ALL PRIVILEGES FROM 角色
REVOKE ALL PRIVILEGES FROM 'role_name' 是非法语法，MySQL 8.0 直接报错 ERROR 1064 (42000)。角色不是权限集合体，而是权限容器；你不能对容器“清空”，只能对“谁用了它”做操作。
真正要清理的是绑定关系，不是角色内部——哪怕你删光角色里的所有权限，只要用户还绑着它，下次 SET ROLE 就又生效了。
- 想彻底废掉一个角色，用
DROP ROLE 'role_name'，但前提是先解绑所有用户 - 试图手动删
mysql.role_edges表记录？风险极高，权限缓存可能不一致，导致部分连接拒绝服务或权限残留 - 角色权限变更（如
REVOKE SELECT ON db.* FROM 'role_name'）只影响新绑定该角色的用户，不影响已绑定者
解绑后权限没变？检查是否还有其它来源
执行完 REVOKE 'reader_role' FROM 'alice'@'localhost' 后，如果 alice 还能查表，说明权限来自别处：可能是显式授予的数据库级权限，也可能是另一个角色，甚至空用户（''@''）带来的隐式权限。
必须分层排查：
- 运行
SHOW GRANTS FOR 'alice'@'localhost'，确认输出中已无reader_role - 再执行
SHOW GRANTS FOR 'alice'@'localhost' USING 'other_role'，检查是否还绑着别的角色 - 查空用户授权：
SELECT Host, Db, Select_priv FROM mysql.db WHERE User = '' AND Host = ''，这类记录不会出现在SHOW GRANTS中，但会影响实际权限
解绑角色后旧连接仍有效
MySQL 权限变更不自动同步到已建立的连接。用户只要没断开客户端、没重置角色状态，就继续持有解绑前的所有权限。
验证是否真正生效，必须：
- 让应用重连，或手动在当前会话执行
SET ROLE NONE再SET ROLE DEFAULT - 不要依赖
FLUSH PRIVILEGES——它对角色绑定无效，只用于直接改系统表后的场景 - 最稳妥的验证方式：新开一个连接，用
SELECT CURRENT_ROLE()和SHOW GRANTS确认角色已消失
角色解绑本身很简单，但权限叠加模型决定了“看起来撤掉了”和“实际没生效”之间常隔着一层缓存、一个隐式授权、或另一个未察觉的角色。生产环境务必在新连接里验证，而不是信 Query OK。
