因为grant角色给用户仅建立绑定关系，不自动激活权限；必须执行set default role或set role显式激活，否则登录后仍报access denied。
角色授给用户后为什么还是Access denied
因为 GRANT 'role_name' TO 'user'@'host'; 只是建立绑定关系，不激活权限。MySQL 8.0 默认不会自动启用任何角色，哪怕你刚把 admin_role 授给了 api_user，该用户登录后执行 SELECT 依然报错。
必须显式激活：要么在连接后立刻执行 SET ROLE 'role_name';，要么设置默认角色让每次连接自动加载。
- 只执行
GRANT 'reader' TO 'api_user'@'%';→ 用户无实际权限 - 补上
SET DEFAULT ROLE 'reader' TO 'api_user'@'%';→ 下次连接即生效 - 若已连上，当前会话需手动
SET ROLE 'reader';才能用（SET ROLE NONE;可临时禁用）
如何确认角色是否真正激活了
SHOW GRANTS FOR 'user'@'host'; 默认不显示角色权限，容易误判“没配好”。它只列出直接授予用户的权限，角色继承的权限被隐藏。
查角色带来的权限，必须加 USING 子句：
SHOW GRANTS FOR 'api_user'@'%' USING 'reader';
验证当前会话是否激活了角色：
-
CURRENT_ROLE()返回NULL→ 角色未激活 -
CURRENT_ROLE()返回'reader'→ 已激活，权限可用了 - 查绑定关系：
SELECT * FROM mysql.role_edges WHERE to_user = 'api_user' AND to_host = '%';
SET DEFAULT ROLE ALL 为什么不能乱用
SET DEFAULT ROLE ALL TO 'dev'@'localhost'; 虽然方便，但会让所有已授予的角色全部激活，违反最小权限原则——比如一个只需读库的开发账号，可能顺带拿到了 CREATE DATABASE 权限。
更安全的做法是明确指定角色名：
-
SET DEFAULT ROLE 'ro_report', 'rw_app' TO 'dev'@'localhost';（只激活需要的） - 避免嵌套超过 2 层，否则
SHOW GRANTS ... USING查不到深层角色来源 - 角色名含特殊字符（如
ci-pipeline）必须用反引号：SET DEFAULT ROLE `ci-pipeline` TO 'user'@'%';
为什么改了角色权限但旧连接看不到变化
角色权限变更（比如给 reader 新增了 UPDATE）对已有连接完全无效——MySQL 不动态刷新角色状态。即使你执行了 GRANT UPDATE ON app.* TO 'reader';，正在运行的应用仍只有旧权限。
必须让应用重连，或在当前会话中手动刷新角色上下文：
- 已登录用户：先
SET ROLE NONE;，再SET ROLE 'reader'; - 应用层：重启服务、清空连接池、或在连接初始化 SQL 中加
SET ROLE 'reader'; - 别依赖
FLUSH PRIVILEGES;—— 它对角色权限无效，也不影响角色绑定和激活逻辑
真正卡住人的从来不是语法，而是“以为绑上了就等于能用”——角色要经过三步才能落地：创建 → 授权 → 绑定 → 激活。漏掉最后一步，前面全白干。
