MySQL 8.0+创建带角色用户必须完成五步闭环:CREATE ROLE建角色、GRANT授予权限给角色、CREATE USER建用户、GRANT将角色分配给用户、SET DEFAULT ROLE启用角色;缺任一环权限均不生效。
CREATE ROLE后必须先GRANT权限,否则角色是空的
角色创建后不带任何权限,哪怕叫
,它也只是一个空容器。执行
只是在
里写入一条元数据,没赋权就等于没配置。
是对角色授权,不是对用户
角色不支持列级权限:
会报错
系统级权限可以授给角色,但不能加
,否则报错
角色名含
或
时,必须用反引号:比如
GRANT角色给用户 ≠ 权限生效,必须SET DEFAULT ROLE
很多人执行了
就以为完事了,结果用户一连上去还是
。这是因为
只建立绑定关系,不激活权限。
必须显式执行
,后续所有新连接才会自动激活
host必须精确匹配:如果角色是授给
,就不能对
设默认角色
一个用户可被授予多个角色,但
要求该用户已在
中存在对应记录,否则报
普通用户无法执行
,需
或
权限
验证角色是否真生效,别只看SHOW GRANTS FOR
只会显示
这一行,不会展开角色内部的
权限——这不是权限没配好,而是MySQL默认行为。
MySQL(Linux)
MySQL 9.6.0是面向Linux平台的2026年创新版本,核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层,确保所有数据变更均被完整记录至Binlog,彻底解决了CDC(变更数据捕获)与主从复制中的数据不一致难题。此外,该版本引入container_aware启动选项以原生适配容器环境,并对审计日志进行了组件化重构,为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
查角色带来的真实权限,必须加
子句:
确认角色是否已激活:
,返回
说明根本没激活
查用户被授予了哪些角色:
旧版客户端(如 MySQL 5.7 客户端连 8.0 服务端)可能忽略角色信息,建议用
验证
SET ROLE切换会话角色时权限互斥,不是叠加
执行
后,之前激活的
权限立刻失效。这不是bug,是MySQL会话级角色模型的设计逻辑。
是即时生效、覆盖式切换,不是追加
若需同时使用多组权限,只能设多个默认角色:
设为
表示登录后不自动激活任何角色,哪怕已授予权限
即使
成功,若连接时未指定
(尤其旧客户端),角色也可能不加载
真正容易被跳过的不是语法,而是这三步闭环:创建角色 → 给角色
→
角色给用户 →
。漏掉任意一环,权限就停在“挂载但未启用”状态。
admin_roleCREATE ROLE 'app_writer'mysql.role_edgesGRANT SELECT, INSERT ON myapp.* TO 'app_writer'GRANT SELECT(col1)WITH GRANT OPTION-.GRANT SELECT ON logs.* TO `ci-pipeline`GRANT 'app_writer' TO 'dev1'@'%'Access deniedGRANT role TO userSET DEFAULT ROLE 'app_writer' TO 'dev1'@'%''dev1'@'%''dev1'@'localhost'SET DEFAULT ROLE ALL TOmysql.role_edgesERROR 3530SET DEFAULT ROLEAPPLICATION_PASSWORD_ADMINSYSTEM_VARIABLES_ADMINSHOW GRANTS FOR 'dev1'@'%'GRANT 'app_writer' TO ...SELECTUSINGSHOW GRANTS FOR 'dev1'@'%' USING 'app_writer'SELECT CURRENT_ROLE()NULLSELECT * FROM mysql.role_edges WHERE to_user = 'dev1' AND to_host = '%'mysql --version ≥ 8.0.11SET ROLE 'app_writer''app_reader'SET ROLESET DEFAULT ROLE 'app_reader', 'app_writer' TO 'dev1'@'%'SET DEFAULT ROLE NONE TOSET DEFAULT ROLE--default-auth=mysql_native_passwordGRANTGRANTSET DEFAULT ROLE