在 MySQL 8.0 中，角色并不会在授权后自动生效，必须通过 SET ROLE 'role' 或配置 DEFAULT ROLE 来显式启用，否则对应权限不会真正执行；另外，SHOW GRANTS 默认也不会直接展示角色继承的权限，通常需要配合 USING 子句才能查看；还有一个容易忽视的参数 mandatory_roles，它会强制为用户附加角色，并且无法直接撤销。
角色没有激活，授权后的权限就不会真正生效
MySQL 8.0 的角色机制并不是“授权完成立即可用”，更像是一把上锁的权限工具箱：先用 GRANT 把权限授给角色，再用 GRANT 将角色分配给用户，这只是完成了配置步骤，但并未真正启用。若此时 CURRENT_ROLE() 返回 NULL，就说明角色仍未激活，相关权限自然不会生效。
常见报错场景是：执行 SELECT * FROM sales.orders; 时出现 ERROR 1142 (42000): SELECT command denied，但查看 SHOW GRANTS FOR 'dev_user'@'%' 又似乎没有问题，这往往就是因为角色尚未启用。
- 临时激活当前会话中的角色：
SET ROLE 'analyst';（必须明确写出角色名，不能只写SET ROLE） - 设置为默认角色（更推荐）：
ALTER USER 'dev_user'@'%' DEFAULT ROLE 'analyst';，这样用户下次登录时会自动启用 - 谨慎使用全局开关：
SET PERSIST activate_all_roles_on_login = ON;，该设置会影响所有新建连接，并且重启后依然保留
需要注意的是：SET ROLE 仅对当前连接或当前会话有效；像 DBea ver、Na vicat 这类数据库工具经常使用连接池，断开后重新连接时，通常还需要再次手动激活角色。
SHOW GRANTS 查不到角色权限，并不代表没有授权成功
SHOW GRANTS FOR 'dev_user'@'%' 默认展示的是直接授予该用户的权限信息，不会自动展开角色中包含的权限内容——这是 MySQL 的设计逻辑，并不是程序异常或 bug。
如果要真正查看角色带来的权限，需要加上 USING 子句，例如：SHOW GRANTS FOR 'dev_user'@'%' USING 'analyst';
- 前提条件是该角色已经绑定给用户（
GRANT 'analyst' TO 'dev_user'@'%'），并且当前会话中的角色也已经激活（CURRENT_ROLE()返回'analyst'） - 如果使用
USING查询后仍然没有结果，建议先检查角色绑定关系：SELECT * FROM mysql.role_edges WHERE to_user = 'dev_user' AND to_host = '%'; - 角色名称必须包含准确的主机部分，
'analyst'@'%'和'analyst'在 MySQL 中会被视为两个不同的角色
角色权限只会在匹配的数据库与上下文中生效
如果角色授予的是 sales.* 的权限，但用户实际执行的是 USE otherdb; SELECT * FROM orders;，依然会报权限错误——因为角色权限不会自动跨库继承，也不会在错误的上下文中生效。
以下细节非常容易被忽略：
- 执行 SQL 前先确认当前数据库：
SELECT DATABASE();，若返回NULL，说明当前未选择数据库，很多表操作都会因此失败 - 角色权限中的库名、表名、主机名都需要严格匹配，且区分大小写；例如
GRANT SELECT ON Sales.*并不等同于sales.* - 函数权限（
FUNCTION）在 MySQL 中可能会被自动转换为过程权限（PROCEDURE），从而导致实际执行时出现权限不匹配的问题
mandatory_roles 会让角色被“强制附加”，而且无法直接删除
如果在 my.cnf 中配置了 mandatory_roles = 'auditor'@'%'，或者曾执行过 SET PERSIST mandatory_roles = '''auditor''@''%'''，那么这个角色就会变成所有用户登录时自动附带的强制角色，相当于一层隐藏的默认权限。
这种情况通常很隐蔽，主要表现为：
SHOW GRANTS FOR 'dev_user'@'%'不会显示该角色，但CURRENT_ROLE()中却可能包含'auditor'@'%'REVOKE 'auditor'@'%' FROM 'dev_user'@'%'或DROP ROLE 'auditor'@'%'都会执行失败- 若要清空该配置，只能使用：
SET PERSIST mandatory_roles = '';，而且只对新连接生效，现有连接不会立刻受到影响
很多人排查 MySQL 角色授权无效问题时，真正卡住的并不是创建角色或分配权限，而是“角色激活”这个容易被忽略的关键步骤——它通常不会报错、不会提示，也不会明显记录日志，却会让权限看起来像是失效了一样。排查时不要只看 SHOW GRANTS，务必要顺手执行一次 CURRENT_ROLE() 来确认当前角色状态。
