在MySQL 8.0及之后版本中，Role（角色）是一种命名的权限集合，它把零散的库表操作权打包成一个逻辑单元，再分配给具体用户。通过角色机制，我们可以把“只读查询”和“业务写入”拆成不同权限模型，避免开发人员拿到全库dump权限。下面以实际操作为主线，说明如何用Role完成读写权限的精确控制。
一、创建角色并授予精确读写权限
角色本身不对应登录账号，只是权限容器。使用CREATE ROLE语句建立角色后，再通过GRANT把特定库的读或写权限绑定上去。例如，我们只希望报表系统读取业务数据，就建立一个只读角色，仅授权SELECT；给交易服务建立一个写入角色，授权INSERT、UPDATE，但收回DELETE和DDL。
这种拆分方式让权限边界非常清楚：读角色永远无法篡改数据，写角色也被限制不能删表。当业务扩容新增账号时，只需把已有角色赋给它，不必重复写一长串grant命令。以下示例展示角色的创建与授权过程：
-- 创建只读角色和写入角色 CREATE ROLE 'role_read_report', 'role_write_trade'; -- 只读角色仅允许查询shop库的所有表 GRANT SELECT ON shop.* TO 'role_read_report'; -- 写入角色允许插入和更新，但禁止删除与结构修改 GRANT INSERT, UPDATE ON shop.* TO 'role_write_trade'; -- 查看角色权限 SHOW GRANTS FOR 'role_read_report';
二、将角色分配给用户并控制激活状态
角色建好之后，要用GRANT把角色挂到用户上。需要注意，MySQL中分配给用户的角色默认可能处于未激活状态，用户登录后并不会自动拥有角色权限，必须显式激活，或者在全局设置默认角色。这样设计的好处是：同一个账号在管理终端可以临时激活高权角色，在日常程序里只用低权角色，降低误操作面。
我们通过SET DEFAULT ROLE为用户指定登录即生效的角色，也可以让用户自己用SET ROLE切换。下面代码演示用户创建、角色指派以及默认角色设定，并给出激活验证方法：
-- 创建两个业务账号 CREATE USER 'report_app'@'192.168.0.1' IDENTIFIED BY 'pwd123'; CREATE USER 'trade_app'@'192.168.0.1' IDENTIFIED BY 'pwd123'; -- 分配对应角色 GRANT 'role_read_report' TO 'report_app'@'192.168.0.1'; GRANT 'role_write_trade' TO 'trade_app'@'192.168.0.1'; -- 设置登录后默认激活的角色 SET DEFAULT ROLE 'role_read_report' TO 'report_app'@'192.168.0.1'; SET DEFAULT ROLE 'role_write_trade' TO 'trade_app'@'192.168.0.1'; -- 用户登录后查看当前激活角色 SELECT CURRENT_ROLE();
三、权限回收与角色复用维护
当业务规则变化，比如报表账号突然需要临时统计汇总，但依然不能看用户隐私表，我们可以直接在角色上做REVOKE或追加GRANT，所有成员自动继承变更。这比逐个修改用户权限高效得多，也减少了漏改导致的越权漏洞。若某账号离职或转岗，只需收回角色，而不必理清它曾被单独授予过哪些表权。
下例展示如何回收写入角色的删除隐患（即便之前没给，也可演示规范做法），以及如何从用户身上剥离角色。结合角色复用，运维人员能把权限审计集中在几个角色定义上，而不是散落在上百个用户里：
-- 确保写入角色没有危险权限（演示回收语法） REVOKE DELETE ON shop.* FROM 'role_write_trade'; -- 临时给只读角色开放某张日志表的查询（角色变更即时生效） GRANT SELECT ON shop.access_log TO 'role_read_report'; -- 用户转岗，收回角色 REVOKE 'role_read_report' FROM 'report_app'@'192.168.0.1'; -- 删除废弃角色 DROP ROLE 'role_read_report';
四、读写控制中的常见误区与建议
一个容易混淆的概念是：很多人以为把角色授予用户后，用户立刻具备全部角色权限。实际上在MySQL里，若没设默认角色且未手动SET ROLE，会话当前角色可能是NONE，此时即便有角色也用不了。另一个误区是在写角色里图省事直接给ALL PRIVILEGES，这违背了精确控制初衷，让读写分离失去意义。
建议生产环境遵循最小权限原则：读角色只用SELECT，写角色明确列出INSERT、UPDATE甚至按表细分；用mysql.role_edges和SHOW GRANTS定期检查角色绑定。这样既能满足业务对数据读写的基本需求，也能在故障排查时快速定位某个账号“为什么能改这张表”。
| 角色类型 | 建议授权 | 禁止授权 |
|---|---|---|
| 只读角色 | SELECT（指定库表） | INSERT、UPDATE、DELETE、DDL |
| 写入角色 | INSERT、UPDATE（指定库表） | DELETE、DROP、ALTER |
| 管理角色 | 按运维需要单独建 | 不直接挂业务账号 |
通过Role角色管理，MySQL的读写权限从“对用户零散授权”升级为“对岗位模型授权”。当系统里有几十个微服务账号时，这种玩法能显著降低权限配置出错率，也让安全审计从翻用户列表变成读角色定义。