MySQL 8.0 不支持 SELECT ... AS ROLE 语法，执行会报 ERROR 1064；唯一合法角色切换方式是 SET ROLE，需配合 GRANT 和 DEFAULT ROLE 使用，且权限叠加不隔离，SET ROLE NONE 才能真正收权。
MySQL 8.0 中没有 AS ROLE 语法，直接使用会报错 ERROR 1064 —— 这是常见误解，源于混淆了 PostgreSQL 或 Oracle 的用法。
为什么执行 SELECT ... AS ROLE 'reader' 会失败
MySQL 不支持在 SQL 语句中用 AS ROLE 切换上下文权限。它的角色激活机制完全基于会话级命令，而非查询修饰符。任何尝试在 SELECT、INSERT 等语句后加 AS ROLE 的写法，都会触发语法错误：ERROR 1064 (42000): You have an error in your SQL syntax。
这个错误和 MySQL 版本无关，8.0.x 全系列都不识别该语法；它也不是权限不足导致的，而是解析器根本无法识别该 token。
SET ROLE 是唯一合法的角色切换方式
MySQL 中启用/切换角色权限，只允许通过 SET ROLE 语句在当前会话中显式激活已授予的角色。它不是“临时降权”或“以某角色身份执行单条语句”，而是改变整个会话的活跃角色集合。
-
SET ROLE 'app_ro';—— 激活指定角色（前提是该角色已被GRANT给当前用户） -
SET ROLE NONE;—— 清空当前会话所有活跃角色，仅保留用户直授权限（如有） -
SET ROLE DEFAULT;—— 切回由SET DEFAULT ROLE预设的默认角色 - 执行后立即生效，
CURRENT_ROLE()可验证结果
注意：SET ROLE 要求用户至少拥有一个被授予的角色，否则报错 ERROR 3535 (HY000): Access denied; you need (at least one of) the ROLE_ADMIN privilege(s) for this operation —— 实际上普通用户只要被授过角色，就能执行 SET ROLE 自己的角色，无需 ROLE_ADMIN；该错误通常意味着角色未被正确授予或主机名不匹配（如角色是 'app_ro'@'localhost'，但用户是 'user'@'10.20.30.%'）。
连接池与应用中如何安全模拟“按需切角色”
应用层无法靠单条 SQL 切换角色，必须依赖连接初始化或会话控制。常见做法有：
- JDBC 连接串加参数：
sessionVariables=default_role=app_ro，让每次连接自动激活角色 - HikariCP 配置
connection-init-sql="SET ROLE 'app_ro'"（注意：不能用SET DEFAULT ROLE，后者只对管理员有效） - 业务代码在获取连接后、执行关键查询前，主动调用
SET ROLE 'xxx'；执行完再SET ROLE NONE（需确保连接不被复用到其他上下文） - 避免在长连接中频繁
SET ROLE，因为角色状态不会跨事务持久化，且部分中间件可能缓存初始权限状态
最关键的一点：MySQL 的角色切换不是原子性的权限沙箱，它不隔离数据可见性或防止越权访问——如果用户本身被直授了 SELECT ON *.*，那么 SET ROLE 'app_ro' 并不能限制其查看其他库，只会叠加权限。角色只增不减，SET ROLE NONE 才是真正收权动作。
替代方案：用 DEFINER 存储过程封装受限操作
若目标是“以某角色权限执行特定逻辑”，更安全的做法是绕开会话角色切换，改用存储过程 + SQL SECURITY DEFINER：
- 创建一个由角色用户（如
'app_ro'@'%'）定义的存储过程：CREATE DEFINER = 'app_ro'@'%' PROCEDURE get_user_list() ... - 调用者只需有
EXECUTE权限，实际执行时以DEFINER身份运行，自动获得该账户/角色的所有权限 - 这种方式天然隔离权限边界，且不依赖客户端是否执行了
SET ROLE - 缺点是灵活性低，每个受限操作都要提前定义好过程
别指望靠语法糖实现 RBAC 安全边界。MySQL 的角色系统本质是权限分组+显式激活，所有“切换”都必须落在 SET ROLE 或连接初始化链路上。漏掉 SET DEFAULT ROLE 或连错 host，CURRENT_ROLE() 就永远是 NONE —— 这个细节，90% 的线上故障都栽在这儿。
