MySQL 8.0无原生权限继承，所谓“继承”实为角色嵌套+显式激活的组合效果；不设默认角色或不执行SET ROLE，用户无法获得角色权限。

MySQL 8.0 没有原生的“权限继承”概念，所谓继承只是角色嵌套 + 显式激活的组合效果；不设默认角色、不执行 SET ROLE，用户就拿不到角色里的任何权限。

为什么直接 GRANT 用户权限不算继承

给用户授 GRANT SELECT ON mydb.* TO 'u'@'%' 是扁平授权，不是继承。它写入 mysql.db 表，只对 mydb 生效，不会自动覆盖或延伸到新库、新表、新列——哪怕你后来建了 mydb2 或 mydb.new_table，也得重新授权。这种模式无法复用、难审计、改起来要逐条操作。

常见误操作是以为 “授了 mydb.* 就等于管住所有子对象”，结果上线新表后应用报 SELECT command denied，却查不出哪条 GRANT 漏了。

• 权限匹配走的是 user → db → tables_priv → columns_priv 逐层短路判断，不是叠加计算
• SHOW GRANTS FOR 'u'@'%' 只显示 GRANT 语句历史，不反映实际生效权限（比如 user 表有全局 SELECT，但 db 表没配，SHOW GRANTS 就不显示）
• 旧版 MySQL（如 5.7）甚至不支持角色，强行模拟“继承”只能靠脚本批量 GRANT，极易出错

用角色嵌套实现可维护的权限复用

角色本身不自动生效，必须通过 GRANT role_name TO user 绑定，再用 SET DEFAULT ROLE 或 SET ROLE 激活。嵌套的关键在于：一个角色可以被授予另一个角色，形成权限链。

例如想让 app_writer 拥有 app_reader 的全部权限 + 额外写权限：

CREATE ROLE 'base_connect', 'app_reader', 'app_writer';
GRANT USAGE ON *.* TO 'base_connect';
GRANT SELECT ON app_db.* TO 'app_reader';
GRANT 'base_connect' TO 'app_reader';  -- 嵌套：app_reader 继承 base_connect
GRANT 'app_reader' TO 'app_writer';   -- 再嵌套：app_writer 继承 app_reader
GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'app_writer';

这样后续只需调整 app_reader 的 SELECT 权限，所有绑定 app_writer 的用户就自动获得更新后的读权限。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 嵌套不支持循环，GRANT r1 TO r2; GRANT r2 TO r1; 会报错
• 角色之间没有隐式激活关系，SET ROLE 'app_writer' 不会自动激活 app_reader —— 必须提前在角色定义里用 GRANT 显式嵌套
• 用户必须先有 USAGE（连接权限），才能被授予任何角色；否则 GRANT 'r1' TO 'u'@'%' 会失败

激活角色才是权限落地的最后一步

用户登录后默认没有任何角色激活，哪怕你已经 GRANT 'app_writer' TO 'u'@'%'，SELECT 仍会报错。必须显式激活：

• 会话级激活：SET ROLE 'app_writer'; —— 仅当前连接有效
• 设为默认：SET DEFAULT ROLE 'app_writer' FOR 'u'@'%'; —— 下次登录自动激活
• 激活多个角色：SET DEFAULT ROLE 'app_reader', 'monitor_role' FOR 'u'@'%';

容易踩的坑：

• 忘记设默认角色，导致应用连上后权限为零，排查时发现 SELECT CURRENT_ROLE(); 返回 NONE
• 用 SET ROLE NONE; 清空后没再 SET 回去，会话彻底失权
• 角色名大小写敏感（取决于系统变量 lower_case_table_names），SET ROLE 'App_Writer' 和创建时的 'app_writer' 不匹配

权限变更后为什么用户没立刻生效

角色权限修改（如 GRANT SELECT ON app_db.logs TO 'app_reader'）会立即写入系统表，但已有连接不会自动刷新角色权限。用户必须重新执行 SET ROLE 或断开重连。

生产环境常见问题：

• 运维改完角色权限，开发说“还是查不了 logs 表”——其实是应用连接池里的长连接没重置角色
• 用 DROP ROLE 删除角色后，已绑定该角色的用户不会自动解绑，SHOW GRANTS 仍显示该角色，但激活会失败
• 权限回收建议用 REVOKE 'app_reader' FROM 'u'@'%'，而不是直接删 mysql.role_edges 表，后者绕过权限校验机制

真正麻烦的不是配置，而是角色激活状态的生命周期管理——它游离于连接之外，又强依赖连接上下文。一个没设默认角色、又没在应用代码里加 SET ROLE 的服务账号，上线即不可用。