MySQL 角色设为默认后连接中为何仍未激活

执行 SET DEFAULT ROLE 后，当前连接里的角色仍未激活，通常不是语句失效，而是把“账户默认角色”和“当前会话活跃角色”当成了同一件事。前者是账户配置，决定用户下一次登录时默认激活什么；后者保存在已经建立的会话中。要让当前连接立即采用默认角色，应执行 SET ROLE DEFAULT，或者断开并重新建立物理连接。

设置完默认角色后连接仍未激活，绝大多数场景要么是数据库没开启`activate_all_roles_on_login`全局参数，要么是设置默认角色前已经存在的旧会话不会自动刷新角色状态。

本文依据 MySQL 8.4 官方手册：https://dev.mysql.com/doc/refman/8.4/en/roles.html、https://dev.mysql.com/doc/refman/8.4/en/set-default-role.html 和 https://dev.mysql.com/doc/refman/8.4/en/set-role.html。

先让当前连接采用默认角色

如果你已经在管理员连接中设置了默认角色，而业务连接的 CURRENT_ROLE() 仍显示 NONE，先在业务连接自身执行下面三句。关键是第二句：它读取当前认证账户的默认角色集合，并把它应用到这个会话。

-- 查看当前物理连接已经激活的角色。
SELECT CURRENT_ROLE();

-- 让当前会话切换为账户此刻配置的默认角色集合。
SET ROLE DEFAULT;

-- 再次确认会话角色已更新，不应继续盲猜授权是否生效。
SELECT CURRENT_ROLE();

SET ROLE DEFAULT 只改变当前会话，不会替其他连接批量刷新。反过来，SET DEFAULT ROLE 只定义账户默认值：当用户连接并完成认证，或者会话主动执行 SET ROLE DEFAULT 时，这组默认值才会被采用。两个语句名称很像，但作用层完全不同。

默认角色和当前角色不是同一层状态

MySQL 把角色看成一组命名权限。GRANT role TO user 表示账户拥有该角色，SET DEFAULT ROLE 从已授予角色中选择登录默认项，SET ROLE 则决定当前会话里哪些角色实际处于活跃状态。只有处于活跃状态的角色，其权限才参与当前会话的权限判断。

因此，已经打开的连接不会因为管理员在另一个会话执行了 SET DEFAULT ROLE 就自动换角色。这样设计也避免了运行中的会话在毫无感知的情况下突然获得或失去一组角色权限。对故障排查来说，可以把三个状态分开看：

配置时要先授权，再设置默认值

命名角色必须存在并且已经授予目标账户，才能被列入该账户的默认角色。下面以只读报表角色为例，先授权，再设为默认。账户的用户名和主机部分都要写完整。

-- 把角色授予应用账户；这里的角色主机省略后按 % 处理。
GRANT 'report_reader' TO 'app'@'%';

-- 只把 report_reader 设为该账户的登录默认角色。
SET DEFAULT ROLE 'report_reader' TO 'app'@'%';

-- 展开角色权限，确认角色本身包含预期的对象权限。
SHOW GRANTS FOR 'app'@'%' USING 'report_reader';

如果账户需要默认激活所有已授予角色，可以使用 SET DEFAULT ROLE ALL TO 'app'@'%'；若希望登录时不默认激活任何角色，则使用 NONE。在生产账号上不宜为了省事一律设置 ALL，因为以后新增的授权角色也会进入默认集合，容易突破最小权限边界。

核对实际认证账户，尤其是 host 部分

'app'@'%' 与 'app'@'localhost' 是两个不同账户。你可能给前者设置了默认角色，但本机连接实际匹配了后者。直接会话中，USER() 表示客户端提交的登录身份，CURRENT_USER() 表示服务器实际用于认证和权限判断的账户，排查角色时以后者为准。

-- 同时查看客户端登录标识、实际认证账户和当前活跃角色。
SELECT USER(), CURRENT_USER(), CURRENT_ROLE();

-- 按上一步得到的精确账户检查直接权限与角色授权。
SHOW GRANTS FOR 'app'@'localhost';

-- 若实际账户不同，应把默认角色配置到真正命中的账户上。
SET DEFAULT ROLE 'report_reader' TO 'app'@'localhost';

这里不要通过直接修改 mysql.default_roles 系统表“修数据”。使用账户管理语句能让服务器校验角色是否存在、是否已授予账户，并减少配置表之间不一致的风险。设置其他用户的默认角色还需要相应管理权限；普通业务账号不应承担这项职责。

连接池为什么让问题更明显

应用日志里常见一种看似随机的现象：同一个服务有些请求获得新权限，有些请求仍报权限不足。原因往往不是 MySQL 随机，而是连接池同时保留了新旧物理连接。新建连接在认证时读取新的默认角色；池中原有连接一直没有断开，仍保留各自原来的活跃角色集合。

处理方式有两种。第一种是在变更窗口中回收连接池，让旧物理连接逐步关闭并重新认证；它最直观，但需要评估连接重建对流量和数据库的影响。第二种是在框架提供的连接初始化或借出钩子中执行 SET ROLE DEFAULT。如果业务会在同一会话里有意切换到其他角色，就不能无条件在每次借出时覆盖，应把角色恢复规则写成明确的连接生命周期契约。

-- 连接池初始化或确认需要复位时，恢复账户默认角色。
SET ROLE DEFAULT;

-- 把检查结果记录到应用诊断日志，便于区分新旧物理连接。
SELECT CONNECTION_ID(), CURRENT_USER(), CURRENT_ROLE();

注意“逻辑连接关闭”未必代表 TCP 连接真正关闭。许多驱动的 close() 只是把连接放回池中，所以测试时必须确认物理连接是否被销毁。仅重试一次业务 SQL，可能又借到同一条旧连接，不能证明默认角色配置有问题。

登录变量可能改变默认激活规则

MySQL 的 activate_all_roles_on_login 默认关闭。关闭时，成功登录后按账户默认角色激活；开启时，新登录会激活账户被授予的全部角色。这个变量只解释登录阶段的行为，仍不意味着服务器会异步刷新已经存在的会话。

-- 查看服务器是否在登录时自动激活全部已授予角色。
SHOW VARIABLES LIKE 'activate_all_roles_on_login';

-- 比对当前会话实际激活结果，避免只根据全局变量推断。
SELECT CURRENT_USER(), CURRENT_ROLE();

如果安全策略要求严格控制默认权限，应同时审查该全局变量和每个账户的默认角色。只检查其中一个会遗漏另一条激活路径。直接授予账户的权限不受 SET ROLE 影响，因此即使 CURRENT_ROLE() 为 NONE，账户仍可能拥有直接权限，这也是“有的表能查、有的表不能查”的常见来源。

一组紧凑的排查顺序

现场排查不需要反复重设角色。按下面顺序可以快速区分是会话旧状态、账户匹配错误，还是角色本身没有正确授权：

1. 在报错的同一条物理连接中查询 CURRENT_USER() 与 CURRENT_ROLE()。
2. 执行 SET ROLE DEFAULT，再次查询 CURRENT_ROLE()。
3. 若成功，问题就是旧会话状态；处理连接池生命周期。
4. 若失败，按 CURRENT_USER() 返回的精确账户检查 SHOW GRANTS。
5. 确认角色已授予账户，再检查默认角色设置与登录激活变量。
6. 最后用一条新建物理连接复查，不要只在旧池连接上循环重试。

最容易记住的区别是：SET DEFAULT ROLE 管“账户以后默认用什么”，SET ROLE DEFAULT 管“这条连接现在用什么”。一旦把账户配置和会话状态分开，角色默认值、连接池复用和权限不足这三类现象就不会再混在一起。