角色是权限的集合，可以为一组具有相同权限的用户创建一个角色，使用角色来管理数据库权限可以简化授权的过程，从而大大提高了开发效率。
然而在实际实践中，居然有一个大坑！————角色没有被激活
这坑有点深，只可惜坑天生就是可以被填的！
下面来复述一下我的踩坑过程。
先创建一个角色
create role R1;
进入一个数据库中，为角色授予权限
use test;
# 将对student表的所有操作权限都赋予给角色R1 grant all on student to R1;
创建一个新用户
# 新用户名字为U1, 登录密码为123456
create user U1@'localhost' identified by '123456';
将角色R1所拥有的权限授予给用户U1
grant R1 to U1@'localhost';
查看此时用户U1所拥有的权限
show grants for U1@'localhost';
# 如果还想知道用户通过角色拥有哪些权限，可以在结尾加个using role，即：
show grants for U1@'localhost' using R1;
会有如下显示：
# USAGE表示无权限
GRANT USAGE ON *.* TO `U1`@`localhost`
# 刚刚通过角色R1授予的权限 GRANT `R1`@`%` TO `U1`@`localhost`
既然如此，不就大功告成了！换用户U1登录验证一下
exit
# 密码为123456 mysql -u U1 -p
此时用户U1应该可以对test数据库中student表进行操作，那就使用test数据库查看一下
use test;
出现了如下错误：
ERROR 1044 (42000): Access denied for user 'U1'@'localhost' to database 'test'
什么鬼，反复检查上述过程，肯定是没错的，那是什么问题啊啊啊啊啊啊。。。
原来是角色没有被激活！
原来是角色没有被激活！
原来是角色没有被激活！
查看角色激活情况
SELECT CURRENT_ROLE();
激活角色有两种方法：
1、非永久激活：
# 第一种方式
set default role all to U1@'localhost'; # 第二种方式
set default R1 to U1@'localhost';
# 注意若此时立即再使用命令select current_role();还是会显示没有角色被激活。
# 我们应该先退出，换用户U1登录再查看
exit
mysql -u U1 -p
select current_role();
# 现在可以看到角色R1已经被激活了
show databases;
use test;
show tables;
select * from student;
2、永久激活：（用户连接到服务器时自动激活所有显式授权和强制角色）
注：默认情况下，禁用自动角色激活。
SET global activate_all_roles_on_login=ON;