MySQL 8.0中CREATE ROLE后用户无权限，是因为角色是空容器，必须严格完成三步：GRANT权限给角色、GRANT角色给用户、SET DEFAULT ROLE或SET ROLE激活；漏任一步均报ERROR 1142，且CURRENT_ROLE()返回NULL才表示未生效。
CREATE ROLE 之后用户依然没权限，不是配置错了，而是 MySQL 8.0 的 RBAC 模型默认不激活角色——必须显式完成三步：给角色授实际权限、把角色授予用户、再设置默认角色或手动激活。漏掉任意一环，SELECT 都会报 ERROR 1142 (42000)。
CREATE ROLE 后为什么 GRANT 角色给用户还是没权限？
刚建的角色是空容器：CREATE ROLE 'reporter' 只在 mysql.role_edges 插入一条记录，但 mysql.tables_priv 等权限表里没有任何条目。
-
GRANT SELECT ON finance.* TO 'reporter'必须单独执行，才能真正赋予权限 -
SHOW GRANTS FOR 'reporter'是唯一能确认角色是否已有权限的命令；SHOW GRANTS FOR 'user'@'%'不显示角色继承的权限 - 权限叠加无去重：重复执行
GRANT INSERT ON logs.* TO 'reporter'不报错，也不影响行为
用户登录后仍提示 “SELECT command denied” 怎么办？
最常见误判点：授予角色 ≠ 当前会话拥有权限。MySQL 8.0 默认不激活角色，必须显式激活。
- 让下次登录即生效：
ALTER USER 'dev_user'@'10.20.30.%' DEFAULT ROLE 'reporter' - 当前会话临时生效：
SET ROLE 'reporter'（断开连接即失效） - 全局开关慎用：
SET PERSIST activate_all_roles_on_login = ON，影响所有新连接 - 验证是否激活：
SELECT CURRENT_ROLE()返回'reporter'才算成功
应用连接池（如 HikariCP）怎么确保角色始终生效？
角色是会话级的，而连接池复用连接——旧连接可能没激活角色，新连接又未必自动激活。
- Java 连接串加参数：
sessionVariables=role='reporter'或connection-init-sql=SET ROLE 'reporter' - 避免依赖
DEFAULT ROLE单点配置，连接池初始化时主动 SET 更可靠 - 禁用
WITH GRANT OPTION：所有GRANT语句结尾不加该子句，防止权限扩散 - 删掉匿名用户：
DROP USER ''@'localhost'，这是生产环境高危入口
mandatory_roles 配置导致角色删不掉怎么办？
如果在 my.cnf 中设了 mandatory_roles = 'auditor'@'%'，这个角色就变成隐形强制项：
- 所有用户（含
root）新登录都会自动获得该角色，且无法通过REVOKE或DROP ROLE删除 - 它不出现在
SHOW GRANTS FOR user结果中，但会出现在CURRENT_ROLE()返回值里 - 清空只能用：
SET PERSIST mandatory_roles = ''，没有其他绕过方式 - 注意：修改后已有连接不受影响，仅新连接生效——这点容易被忽略，导致误以为配置没生效
RBAC 在 MySQL 里真正复杂的地方不在建表或赋权，而在于“激活”这个隐式环节：权限链路是 GRANT → GRANT → SET DEFAULT ROLE / SET ROLE / activate_all_roles_on_login，中间漏掉任意一环，整个模型就静默失效。别只查 SHOW GRANTS，一定要用 CURRENT_ROLE()。
