SET ROLE仅在当前会话临时切换角色，立即生效但断开即失效；需确保角色已显式授予且host匹配，不支持叠加，普通用户默认无权执行。
SET ROLE只能在当前会话中临时切换角色
SET ROLE 不是设置默认行为，它只影响当前连接。执行后，权限立即变更，断开重连就失效。它适合调试、临时提权或脚本中按需切换，不适合生产环境长期依赖。
常见错误现象：用户执行了 GRANT 'app_writer' TO 'dev1'@'%'，接着连上去直接 SET ROLE 'app_writer' 却报错 ERROR 3530 (HY000): Cannot grant role 'app_writer' to 'dev1'@'%': role does not exist——根本原因是角色还没被真正授予该用户（mysql.role_edges 中无对应记录），或者 host 不匹配（比如用户用 'dev1'@'localhost' 登录，但角色只授给了 'dev1'@'%'）。
- 必须确保角色已存在：
SELECT COUNT(*) FROM mysql.role_edges WHERE from_user = 'app_writer' - 必须确保用户已被授予该角色：
SELECT * FROM mysql.role_edges WHERE to_user = 'dev1' AND to_host = 'localhost' - 角色名含特殊字符（如
-或.）时，必须用反引号：SET ROLE `ci-pipeline` -
SET ROLE不支持通配符或模糊匹配，只能指定确切存在的角色名
SET ROLE会覆盖当前所有已激活角色，不是叠加
MySQL 的会话级角色模型是“单次生效、互斥替换”。执行 SET ROLE 'app_reader' 后再执行 SET ROLE 'app_writer'，前者权限立刻清空——不会保留 SELECT 权限，也不会叠加 INSERT 权限。
如果你需要同时拥有多个角色的权限，不能靠多次 SET ROLE，而应提前设好默认角色组合，例如：
SET DEFAULT ROLE 'app_reader', 'app_writer' TO 'dev1'@'localhost';
或者在登录时自动激活全部（需全局开启 activate_all_roles_on_login = ON）。
-
SET ROLE ALL激活该用户所有已被授予的角色（前提是mysql.role_edges中有完整记录） -
SET ROLE DEFAULT回退到SET DEFAULT ROLE所定义的角色集 -
SET ROLE NONE清空当前会话所有角色权限，回到仅剩账户自身直授权限的状态
验证SET ROLE是否真生效，别只看SHOW GRANTS
SHOW GRANTS FOR 'dev1'@'localhost' 只显示“被授予了哪些角色”，不反映当前会话实际启用的权限。它永远不展开角色内部的 SELECT 或 INSERT ——这不是配置失败，是 MySQL 的默认展示逻辑。
要确认角色权限是否真的在起作用，必须查运行时状态：
- 查当前激活角色：
SELECT CURRENT_ROLE()，返回'app_writer'表示成功；返回NULL说明没激活 - 查角色带来的具体权限：
SHOW GRANTS FOR 'dev1'@'localhost' USING 'app_writer' - 查用户被授予的所有角色：
SELECT * FROM mysql.role_edges WHERE to_user = 'dev1' AND to_host = 'localhost'
注意：如果使用旧版客户端（如 MySQL 5.7 客户端连接 8.0 服务端），CURRENT_ROLE() 可能返回空或报错，建议统一用 mysql --version ≥ 8.0.11 验证。
普通用户无法执行SET ROLE，权限检查容易被忽略
执行 SET ROLE 不要求 SUPER 权限，但需要 APPLICATION_PASSWORD_ADMIN 或 SYSTEM_VARIABLES_ADMIN——这两个权限通常只给 DBA 或运维账号。普通应用账号即使被授予了角色，也无法自行调用 SET ROLE。
这意味着：应用代码里写 SET ROLE 'app_ro' 会直接报错 ERROR 1227 (42501): Access denied，除非你显式给该用户加了上述权限（不推荐）。
- 生产环境应避免让应用自己执行
SET ROLE，而是靠SET DEFAULT ROLE或activate_all_roles_on_login = ON实现登录即生效 - 测试时若用 root 或高权限账号执行
SET ROLE成功，不代表应用账号也能用 - 权限变更后记得 FLUSH PRIVILEGES？MySQL 8.0+ 大多数情况不需要，但若发现角色元数据未及时同步，可手动执行一次
最常被跳过的一步是确认角色是否真正“授予并匹配”：host 精确性、角色是否存在、用户是否解锁且密码未过期——这些前置条件任一缺失，SET ROLE 就只是个语法正确的无效操作。
