mysql权限和角色有什么区别_mysql权限模型解析

来源：这里教程网时间：2026-02-28 20:40:10 作者：

MySQL权限

和

角色

不是并列概念，而是“原子”与“组合包”的关系：权限是最小可授单位（比如

SELECT

、

UPDATE

），角色是权限的命名集合，本身不直接执行操作，只用于批量分发和统一管理。

权限按层级生效，不是“叠加”而是“短路匹配”

MySQL验证权限时，严格按

user

→

db

→

tables_priv

→

columns_priv

顺序逐层检查，一旦某层匹配到

（允许），就立即停止向下查——不会累加或合并多层权限。

例如：
user
表中
Select_priv = 'Y'
，哪怕
db
表里该用户对某个库设为
'N'
，他依然能查所有库反之，如果
user
表全为
'N'
，才继续看
db
表；若
db
也否，再往下走

SELECT Host, User, Select_priv FROM mysql.user WHERE User = 'dev';
SELECT Host, Db, Select_priv FROM mysql.db WHERE User = 'dev' AND Db = 'mall';

常见踩坑：

直接改
mysql.user
表后忘记执行
FLUSH PRIVILEGES
，权限不生效创建用户时用了
'dev'@'%'
，但误以为
'dev'@'localhost'
也会继承权限——其实它们是完全独立的两个账户 用
GRANT
授了
SELECT
，却没意识到
SHOW CREATE TABLE
还需要
SELECT
或
ALTER
权限（取决于版本）

角色是MySQL 8.0+的“权限模板”，不是用户，也不能登录

CREATE ROLE

创建的是纯逻辑容器，它没有密码、不能连接、不存于

mysql.user

表，只在

mysql.role_edges

和

mysql.default_roles

中记录关系。

角色可以被授予其他角色（嵌套），但不能循环引用 用户必须显式
SET DEFAULT ROLE
或
SET ROLE
才能激活角色权限（会话级生效）激活前，即使已
GRANT 'role' TO 'user'@'host'
，该用户仍无任何权限

CREATE ROLE 'app_reader';
GRANT SELECT ON mall.* TO 'app_reader';
GRANT 'app_reader' TO 'reporter'@'%';
SET DEFAULT ROLE 'app_reader' TO 'reporter'@'%';

关键注意点：

MySQL 5.7及更早版本不支持角色，
CREATE ROLE
会报错角色权限变更后，已登录用户的会话不会自动更新，需重新
SET ROLE
或重连
SHOW GRANTS FOR 'user'@'host'
默认不显示角色权限，要加
USING
子句：
SHOW GRANTS FOR 'reporter'@'%' USING 'app_reader';

什么时候该用权限，什么时候该用角色？

核心判断标准就一条：是否有多人共用同一组权限需求

单点授权（如DBA给运维开一个临时备份账号）→ 直接
GRANT
权限，简单明确多人同权（如12个报表开发都要
SELECT
全部业务库）→ 必须用角色，否则每次增删人就要重复6条
GRANT
权限需动态切换（如开发人员白天写SQL、晚上跑ETL）→ 创建
'dev_writer'
和
'etl_runner'
两个角色，用
SET ROLE
按需切换，避免长期持有过高权限

另外：

WITH GRANT OPTION
只能授给用户，不能授给角色（MySQL 8.0.16+才支持角色间传递，且需显式开启
activate_all_roles_on_login=ON
）
root
用户默认不绑定任何角色，它的权限来自
user
表中的
Super_priv='Y'
，不是靠角色继承

权限系统真正的复杂点不在语法，而在于主机名绑定 + 层级短路 + 内存缓存刷新机制三者交织。哪怕