mysql 8.0+ 中 set role 切换会话角色需先 grant 角色给用户并设置 default role，否则报错；权限变更对已存在连接不生效，必须重连或配置连接池初始化 sql。
MySQL 8.0+ 如何用 SET ROLE 切换当前会话角色
MySQL 8.0 引入了角色（ROLE）机制，但很多人误以为 SET ROLE 能像 PostgreSQL 那样自由切换任意角色——实际必须先显式授予该角色给用户，且默认不激活。
常见错误现象：ERROR 3530 (HY000): SET ROLE 'analyst_role' failed: Role 'analyst_role' does not exist for the current user，本质是没执行过 GRANT 'analyst_role' TO 'dev_user'@'%'，或忘了 SET DEFAULT ROLE。
-
SET ROLE 'role_name'只影响当前连接，退出即失效 - 若想新会话自动启用某角色，必须提前执行
SET DEFAULT ROLE 'role_name' TO 'user'@'host' - 不能对未被
GRANT的角色调用SET ROLE，哪怕你有CREATE ROLE权限也不行 - 使用
SELECT CURRENT_ROLE()可验证当前生效角色，返回NULL表示无激活角色
动态增删权限后，为什么 SELECT 还报错？
权限变更不会实时作用于已存在的连接。MySQL 的权限检查发生在语句执行时，但权限缓存只在连接建立时加载一次 —— 即使你刚用 GRANT SELECT ON db.tbl TO 'user'@'%' 加了权限，老连接仍按旧快照校验。
典型场景：开发人员正在调试 SQL，DBA 在另一终端执行了 GRANT，但开发者刷新页面/重跑查询仍报 ERROR 1142 (42000): SELECT command denied to user。
- 必须让客户端断开重连，或执行
FLUSH PRIVILEGES（仅对部分旧权限有效，对角色无效） - 角色权限变更后，
FLUSH PRIVILEGES完全无效，只能重连 - 若用连接池（如 HikariCP），需配置
connection-init-sql=SET ROLE 'xxx'或重启池
REVOKE 后权限没立刻消失？小心隐式继承和角色叠加
MySQL 的权限是“叠加生效”，不是“最后一条为准”。比如用户同时拥有 role_a（含 SELECT）和 role_b（含 INSERT），你 REVOKE role_a FROM user，SELECT 权限是否消失？不一定 —— 如果该用户还被直接授予过 SELECT，或者 role_b 里也包含 SELECT，权限依然存在。
容易踩的坑：SHOW GRANTS FOR 'user'@'%' 只显示显式授予项，不展开角色内容；要查完整权限集，得结合 SELECT * FROM mysql.role_edges WHERE TO_HOST = '%' AND TO_USER = 'user' 和角色定义。
-
REVOKE某角色 ≠ 撤销该角色内所有权限，只是断开用户与角色的绑定 - 用户直授权限 + 角色权限 + 默认角色权限，三者并存，只要任一路径存在，权限就有效
- 用
SHOW GRANTS FOR 'user'@'%' USING 'role_name'可模拟该用户以某角色身份登录时的实际权限
MySQL 5.7 怎么办？没有角色，只能靠 GRANT/REVOKE 手动维护
MySQL 5.7 不支持角色，所谓“动态调整”就是反复执行 GRANT 和 REVOKE，但要注意：每次操作都触发权限表写入和内存重载，高并发下可能短暂出现权限不一致。
性能影响明显：频繁修改权限会导致 mysql.user 表锁竞争，尤其在 FLUSH PRIVILEGES 后，所有连接需重新加载权限缓存。
- 避免在业务高峰期执行权限变更
- 批量授权建议用单条
GRANT包含多个权限（如GRANT SELECT, INSERT ON db.* TO 'u'@'%'），比多条语句更轻量 - 不要依赖
DROP USER清理权限 —— 它会删账号，而REVOKE ALL PRIVILEGES ON *.* FROM 'u'@'%'才是安全撤权方式
角色是 MySQL 8.0 的分水岭，但权限模型的叠加性、缓存行为、连接隔离这些底层逻辑，5.7 和 8.0 其实一脉相承。真正容易被忽略的，是“权限生效时机”永远绑定在连接生命周期上，而不是语句执行那一刻。
