考虑以下场景

为了避免将权限单独授予可能存在的许多用户帐户，请创建角色作为所需权限集的名称。这使得通过授予适当的角色，可以轻松地将所需权限授予用户帐户。

要创建角色，请使用 CREATE ROLE 语句

CREATE ROLE 'app_developer', 'app_read', 'app_write';

角色名称与用户帐户名称非常相似，并以 'user_name'@'host_name' 格式包含用户部分和主机部分。如果省略主机部分，则默认为 '%'。如果用户和主机部分不包含特殊字符（如 - 或 %），则可以不加引号。与帐户名称不同，角色名称的用户部分不能为空。有关更多信息，请参阅 第 8.2.5 节，“指定角色名称”。

要将权限分配给角色，请使用与向用户帐户分配权限相同的语法，执行 GRANT 语句

GRANT ALL ON app_db.* TO 'app_developer';
GRANT SELECT ON app_db.* TO 'app_read';
GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'app_write';

现在假设您最初需要一个开发人员帐户，两个需要只读访问权限的用户帐户和一个需要读写访问权限的用户帐户。使用 CREATE USER 创建帐户。

CREATE USER 'dev1'@'localhost' IDENTIFIED BY 'dev1pass';
CREATE USER 'read_user1'@'localhost' IDENTIFIED BY 'read_user1pass';
CREATE USER 'read_user2'@'localhost' IDENTIFIED BY 'read_user2pass';
CREATE USER 'rw_user1'@'localhost' IDENTIFIED BY 'rw_user1pass';

要为每个用户帐户分配其所需的权限，您可以使用与刚刚显示的相同形式的 GRANT 语句，但这需要为每个用户枚举单独的权限。相反，使用另一种 GRANT 语法，该语法允许授予角色而不是权限。

GRANT 'app_developer' TO 'dev1'@'localhost';
GRANT 'app_read' TO 'read_user1'@'localhost', 'read_user2'@'localhost';
GRANT 'app_read', 'app_write' TO 'rw_user1'@'localhost';

用于 rw_user1 帐户的 GRANT 语句授予读和写角色，它们组合在一起提供了所需的读和写权限。

将角色授予帐户的 GRANT 语法不同于授予权限的语法：有一个 ON 子句用于分配权限，而没有 ON 子句用于分配角色。由于语法不同，您不能在同一语句中混合分配权限和角色。（允许将权限和角色都分配给帐户，但您必须使用单独的 GRANT 语句，每个语句都使用适合要授予内容的语法。）角色不能授予匿名用户。

角色在创建时被锁定，没有密码，并被分配默认身份验证插件。（这些角色属性可以使用 ALTER USER 语句由具有全局 CREATE USER 权限的用户稍后更改。）

在锁定状态下，角色不能用于向服务器进行身份验证。如果解锁，角色可以用于身份验证。这是因为角色和用户都是具有很多共同点的授权标识符，几乎没有区别。另请参见 用户和角色的可互换性。

可以通过在 mandatory_roles 系统变量的值中命名它们来指定角色为强制角色。服务器将强制角色视为授予所有用户，因此无需显式地授予任何帐户。

要在服务器启动时指定强制角色，请在服务器 my.cnf 文件中定义 mandatory_roles。

[mysqld]
mandatory_roles='role1,role2@localhost,r3@%.example.com'

要在运行时设置和持久化 mandatory_roles，请使用以下语句

SET PERSIST mandatory_roles = 'role1,role2@localhost,r3@%.example.com';

SET PERSIST 设置正在运行的 MySQL 实例的值。它还会保存该值，使其在随后的服务器重启时生效。要更改正在运行的 MySQL 实例的值而不会使其在随后的服务器重启时生效，请使用 GLOBAL 关键字而不是 PERSIST。参见 第 15.7.6.1 节“SET 语法用于变量赋值”。

设置 mandatory_roles 需要 ROLE_ADMIN 权限，此外还需要通常用于设置全局系统变量的 SYSTEM_VARIABLES_ADMIN 权限（或已弃用的 SUPER 权限）。

强制角色与显式授予的角色一样，只有在激活后才会生效（参见 激活角色）。在登录时，如果 activate_all_roles_on_login 系统变量已启用，则会为所有授予的角色激活角色，否则会为设置为默认角色的角色激活角色。在运行时，SET ROLE 激活角色。

在 mandatory_roles 值中命名的角色不能使用 REVOKE 撤销，也不能使用 DROP ROLE 或 DROP USER 删除。

要防止会话默认情况下成为系统会话，具有 SYSTEM_USER 权限的角色不能列在 mandatory_roles 系统变量的值中。

即使有这种保护措施，最好也避免通过角色授予 SYSTEM_USER 权限，以防止可能发生的权限提升。

如果在 mandatory_roles 中命名的角色不存在于 mysql.user 系统表中，则该角色不会授予用户。当服务器尝试为用户激活角色时，它不会将不存在的角色视为强制角色，并会向错误日志写入警告。如果该角色稍后创建并因此变得有效，则可能需要使用 FLUSH PRIVILEGES 才能使服务器将其视为强制角色。

SHOW GRANTS 根据 第 15.7.7.22 节“SHOW GRANTS 语句” 中描述的规则显示强制角色。

要验证分配给帐户的权限，请使用 SHOW GRANTS。例如

mysql> SHOW GRANTS FOR 'dev1'@'localhost';
+-------------------------------------------------+
| Grants for dev1@localhost                       |
+-------------------------------------------------+
| GRANT USAGE ON *.* TO `dev1`@`localhost`        |
| GRANT `app_developer`@`%` TO `dev1`@`localhost` |
+-------------------------------------------------+

但是，这将显示每个授予的角色，而不会 “扩展” 它到角色所代表的权限。要显示角色权限，请添加一个 USING 子句，其中命名要显示其权限的授予角色

mysql> SHOW GRANTS FOR 'dev1'@'localhost' USING 'app_developer';
+----------------------------------------------------------+
| Grants for dev1@localhost                                |
+----------------------------------------------------------+
| GRANT USAGE ON *.* TO `dev1`@`localhost`                 |
| GRANT ALL PRIVILEGES ON `app_db`.* TO `dev1`@`localhost` |
| GRANT `app_developer`@`%` TO `dev1`@`localhost`          |
+----------------------------------------------------------+

以类似方式验证其他每种类型的用户

mysql> SHOW GRANTS FOR 'read_user1'@'localhost' USING 'app_read';
+--------------------------------------------------------+
| Grants for read_user1@localhost                        |
+--------------------------------------------------------+
| GRANT USAGE ON *.* TO `read_user1`@`localhost`         |
| GRANT SELECT ON `app_db`.* TO `read_user1`@`localhost` |
| GRANT `app_read`@`%` TO `read_user1`@`localhost`       |
+--------------------------------------------------------+
mysql> SHOW GRANTS FOR 'rw_user1'@'localhost' USING 'app_read', 'app_write';
+------------------------------------------------------------------------------+
| Grants for rw_user1@localhost                                                |
+------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `rw_user1`@`localhost`                                 |
| GRANT SELECT, INSERT, UPDATE, DELETE ON `app_db`.* TO `rw_user1`@`localhost` |
| GRANT `app_read`@`%`,`app_write`@`%` TO `rw_user1`@`localhost`               |
+------------------------------------------------------------------------------+

SHOW GRANTS 根据 第 15.7.7.22 节“SHOW GRANTS 语句” 中描述的规则显示强制角色。

授予用户帐户的角色在帐户会话中可以处于活动状态或非活动状态。如果在会话中授予的角色处于活动状态，则其权限适用；否则不适用。要确定当前会话中哪些角色处于活动状态，请使用 CURRENT_ROLE() 函数。

默认情况下，将角色授予帐户或将其命名在 mandatory_roles 系统变量值中不会自动导致该角色在帐户会话中变为活动状态。例如，因为在前面的讨论中，没有激活任何 rw_user1 角色，所以如果您以 rw_user1 的身份连接到服务器并调用 CURRENT_ROLE() 函数，则结果为 NONE（没有活动角色）

mysql> SELECT CURRENT_ROLE();
+----------------+
| CURRENT_ROLE() |
+----------------+
| NONE           |
+----------------+

要指定用户每次连接到服务器并进行身份验证时应激活哪些角色，请使用 SET DEFAULT ROLE。要将所有分配角色的默认值设置为之前创建的每个帐户，请使用以下语句

SET DEFAULT ROLE ALL TO
  'dev1'@'localhost',
  'read_user1'@'localhost',
  'read_user2'@'localhost',
  'rw_user1'@'localhost';

现在，如果您以 rw_user1 的身份连接，则 CURRENT_ROLE() 的初始值将反映新的默认角色分配

mysql> SELECT CURRENT_ROLE();
+--------------------------------+
| CURRENT_ROLE()                 |
+--------------------------------+
| `app_read`@`%`,`app_write`@`%` |
+--------------------------------+

要使所有显式授予的和强制的角色在用户连接到服务器时自动激活，请启用 activate_all_roles_on_login 系统变量。默认情况下，自动角色激活处于禁用状态。

在会话中，用户可以执行 SET ROLE 来更改活动角色集。例如，对于 rw_user1

mysql> SET ROLE NONE; SELECT CURRENT_ROLE();
+----------------+
| CURRENT_ROLE() |
+----------------+
| NONE           |
+----------------+
mysql> SET ROLE ALL EXCEPT 'app_write'; SELECT CURRENT_ROLE();
+----------------+
| CURRENT_ROLE() |
+----------------+
| `app_read`@`%` |
+----------------+
mysql> SET ROLE DEFAULT; SELECT CURRENT_ROLE();
+--------------------------------+
| CURRENT_ROLE()                 |
+--------------------------------+
| `app_read`@`%`,`app_write`@`%` |
+--------------------------------+

第一个 SET ROLE 语句停用所有角色。第二个使 rw_user1 有效地只读。第三个恢复默认角色。

存储程序和视图对象的有效用户受 DEFINER 和 SQL SECURITY 属性的约束，这些属性决定执行是在调用者上下文中还是定义者上下文中发生（参见 第 27.6 节“存储对象访问控制”）。

正如角色可以授予帐户一样，也可以从帐户中撤销它们

REVOKE role FROM user;

在 mandatory_roles 系统变量值中命名的角色不能撤销。

REVOKE 也可以应用于角色以修改授予它的权限。这不仅影响角色本身，还影响授予该角色的任何帐户。假设您要暂时使所有应用程序用户只读。为此，请使用 REVOKE 从 app_write 角色中撤销修改权限

REVOKE INSERT, UPDATE, DELETE ON app_db.* FROM 'app_write';

碰巧的是，这会使该角色没有任何权限，正如使用 SHOW GRANTS 所看到的（这表明该语句可以与角色一起使用，而不仅仅是用户）

mysql> SHOW GRANTS FOR 'app_write';
+---------------------------------------+
| Grants for app_write@%                |
+---------------------------------------+
| GRANT USAGE ON *.* TO `app_write`@`%` |
+---------------------------------------+

由于从角色中撤销权限会影响分配了已修改角色的任何用户的权限，因此 rw_user1 现在没有表修改权限（INSERT、UPDATE 和 DELETE 不再存在）

mysql> SHOW GRANTS FOR 'rw_user1'@'localhost'
       USING 'app_read', 'app_write';
+----------------------------------------------------------------+
| Grants for rw_user1@localhost                                  |
+----------------------------------------------------------------+
| GRANT USAGE ON *.* TO `rw_user1`@`localhost`                   |
| GRANT SELECT ON `app_db`.* TO `rw_user1`@`localhost`           |
| GRANT `app_read`@`%`,`app_write`@`%` TO `rw_user1`@`localhost` |
+----------------------------------------------------------------+

实际上，rw_user1 读写用户已成为只读用户。这也会发生在授予 app_write 角色的任何其他帐户中，说明了使用角色如何使修改单个帐户的权限变得不必要。

要将修改权限恢复到该角色，只需重新授予它们即可

GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'app_write';

现在，rw_user1 再次具有修改权限，授予 app_write 角色的任何其他帐户也是如此。

要删除角色，请使用 DROP ROLE

DROP ROLE 'app_read', 'app_write';

删除角色会将其从授予该角色的所有帐户中撤销。

在 mandatory_roles 系统变量值中命名的角色不能被删除。

如之前关于 SHOW GRANTS（显示用户帐户或角色的授予权限）的提示，帐户和角色可以互换使用。

角色和用户之间的区别之一是 CREATE ROLE 创建一个默认情况下被锁定的授权标识符，而 CREATE USER 创建一个默认情况下被解锁的授权标识符。您应该记住，这种区别不是一成不变的；拥有适当权限的用户可以在创建角色或（其他）用户后锁定或解锁它们。

如果数据库管理员偏好某个特定的授权标识符必须是角色，则可以使用一种命名方案来传达这种意图。例如，您可以对所有您打算作为角色使用的授权标识符使用 r_ 前缀，而不能使用其他任何前缀。

角色和用户之间的另一个区别在于它们可用于管理它们的权限。

因此，CREATE ROLE 和 DROP ROLE 权限不如 CREATE USER 强大，可以授予那些只允许创建和删除角色的用户，而不允许执行更通用的帐户操作。

关于用户和角色的权限和可互换性，您可以将用户帐户视为角色，并将该帐户授予另一个用户或角色。效果是将该帐户的权限和角色授予另一个用户或角色。

这组语句表明您可以将用户授予用户、将角色授予用户、将用户授予角色或将角色授予角色。

CREATE USER 'u1';
CREATE ROLE 'r1';
GRANT SELECT ON db1.* TO 'u1';
GRANT SELECT ON db2.* TO 'r1';
CREATE USER 'u2';
CREATE ROLE 'r2';
GRANT 'u1', 'r1' TO 'u2';
GRANT 'u1', 'r1' TO 'r2';

在每种情况下，结果都是将与授予对象相关的权限授予受让人对象。执行这些语句后，u2 和 r2 都获得了来自用户 (u1) 和角色 (r1) 的权限。

mysql> SHOW GRANTS FOR 'u2' USING 'u1', 'r1';
+-------------------------------------+
| Grants for u2@%                     |
+-------------------------------------+
| GRANT USAGE ON *.* TO `u2`@`%`      |
| GRANT SELECT ON `db1`.* TO `u2`@`%` |
| GRANT SELECT ON `db2`.* TO `u2`@`%` |
| GRANT `u1`@`%`,`r1`@`%` TO `u2`@`%` |
+-------------------------------------+
mysql> SHOW GRANTS FOR 'r2' USING 'u1', 'r1';
+-------------------------------------+
| Grants for r2@%                     |
+-------------------------------------+
| GRANT USAGE ON *.* TO `r2`@`%`      |
| GRANT SELECT ON `db1`.* TO `r2`@`%` |
| GRANT SELECT ON `db2`.* TO `r2`@`%` |
| GRANT `u1`@`%`,`r1`@`%` TO `r2`@`%` |
+-------------------------------------+

前面的示例仅用于说明，但用户帐户和角色的可互换性具有实际应用，例如在以下情况下：假设一个遗留应用程序开发项目是在 MySQL 中出现角色之前开始的，因此与该项目相关的所有用户帐户都直接被授予权限（而不是通过被授予角色而被授予权限）。这些帐户中的一个是被授予权限的开发人员帐户，其授予权限的方式如下：

CREATE USER 'old_app_dev'@'localhost' IDENTIFIED BY 'old_app_devpass';
GRANT ALL ON old_app.* TO 'old_app_dev'@'localhost';

如果该开发人员离开了项目，则有必要将权限分配给另一个用户，或者如果开发活动已经扩展，则分配给多个用户。以下是处理此问题的一些方法。