1、MySQL用户管理
1.1、验证插件和密码加密办法的变革
在MySQL 8.0中，caching_sha2_password是默认的身份验证插件而不是之前版本的mysql_native_password，默认的密码加密办法是sha2。如果须要保持之前的验证办法并保持之前版本的密码加密办法须要在配置文件中修正，暂不支持动态修正，须要重启生效：default_authentication_plugin = mysql_native_password。
将8.0已有的sha2密码修正为sha1的模式：
ALTER USER 'root'@'127.0.0.1' IDENTIFIED BY 'passowrd' PASSWORD EXPIRE NEVER; #修正加密规则为永不过期
ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY 'password'; #更新一下用户的密码加密办法为之前版本的办法
FLUSH PRIVILEGES; #刷新权限
1.2、用户授权和修正密码
MySQL8.0的用户授权和之前有所差异，老版本的常用授权语句在8.0中会报错：
MySQL8.0之前版本：
GRANT ALL ON . TO wangwei@127.0.0.1 IDENTIFIED BY 'passowrd' WITH GRANT OPTION;
MySQL8.0版本：
CREATE USER wangwei@127.0.0.1 IDENTIFIED BY 'passowrd';
GRANT ALL ON . TO wangwei@127.0.0.1 WITH GRANT OPTION;
MySQL8.0中带过期韶光用户的创建：
CREATE USER wangwei@127.0.0.1 IDENTIFIED BY 'wangwei' PASSWORD EXPIRE INTERVAL 90 DAY;
GRANT ALL ON . TO wangwei@127.0.0.1 WITH GRANT OPTION;
MySQL8.0修正用户密码：
ALTER USER 'wangwei'@'127.0.0.1' IDENTIFIED BY 'wangwei';
1.3、密码过期韶光管理
要全局建立自动密码到期策略，请利用default_password_lifetime系统变量。其默认值为0，禁用自动密码过期。如果值default_password_lifetime正整数N，则表示许可的密码生存期，以便密码必须每天变动N。可以加在配置文件中：
1：要建立全局策略，密码的利用期限大约为六个月，请在做事器my.cnf文件中利用以下行启动做事器：
[mysqld]
default_password_lifetime=180
2：要建立全局策略，以便密码永不过期，请将其设置default_password_lifetime为0：
[mysqld]
default_password_lifetime=0
这个参数是可以动态设置并保存的：
SET PERSIST default_password_lifetime = 180;
SET PERSIST default_password_lifetime = 0;
创建和修正带有密码过期的用户，帐户特定的到期韶光设置示例：
哀求每90天改换密码：
CREATE USER 'wangwei'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;
ALTER USER 'wangwei'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;
禁用密码过期：
CREATE USER ' wangwei'@'localhost' PASSWORD EXPIRE NEVER;
ALTER USER 'wangwei'@'localhost' PASSWORD EXPIRE NEVER;
遵照全局到期政策：
CREATE USER 'wangwei'@'localhost' PASSWORD EXPIRE DEFAULT;
ALTER USER 'wangwei'@'localhost' PASSWORD EXPIRE DEFAULT;
1.4、MySQL用户密码重用策略设置
MySQL许可限定重复利用以前的密码。可以根据密码变动次数、已用韶光或两者来建立重用限定。帐户的密码历史由过去分配的密码组成。MySQL可以限定从此历史记录中选择新密码：
1：如果根据密码变动次数限定帐户，则无法从指天命量的最新密码中选择新密码。例如，如果密码变动的最小数量设置为3，则新密码不能与任何最近的3个密码相同。
2：如果帐户因韶光的限定而被限定，则无法从历史记录中的新密码中选择新密码，该新密码不会超过指定的天数。例如，如果密码重用间隔设置为60，则新密码不得在最近60天内选择的密码之间。
把稳：空密码不记录在密码历史记录中，并随时可以重复利用。
要全局建立密码重用策略，请利用password_history和password_reuse_interval系统变量。要在做事器启动时指定变量值，请在做事器my.cnf文件中定义它们。
示例：
要禁止重复利用最近6个密码或密码超过365天的任何密码，请将这些行放入您的做事器 my.cnf文件中：
[mysqld]
password_history=6
password_reuse_interval=365
要动态设置和保存配置，请利用如下所示的语句：
SET PERSIST password_history = 6;
SET PERSIST password_reuse_interval = 365;
2、MySQL8.0的角色管理
MySQL角色是指定的权限凑集。像用户帐户一样，角色可以拥有付与和撤消的权限。可以付与用户帐户角色，付与该帐户与每个角色干系的权限。用户被付与角色权限，则该用户拥有该角色的权限。
以下列表总结了MySQL供应的角色管理功能：
CREATE ROLE并 DROP ROLE角色创建和删除。
GRANT并 REVOKE为用户和角色分配和撤销权限。
SHOW GRANTS 显示用户和角色的权限和角色分配。
SET DEFAULT ROLE 指定哪些帐户角色默认处于活动状态。
SET ROLE 变动当前会话中的活动角色。
CURRENT_ROLE()功能显示当前会话中的活动角色。
2.1、创建角色并付与用户角色权限
考虑如下几种场景：
运用程序利用名为app_db的数据库 。
与运用程序干系联，可以为创建和掩护运用程序的开拓职员以及管理员账户。
开拓职员须要完备访问数据库。有的用户只须要读取权限，有的用户须要读取/写入权限。
为清楚区分角色的权限，将角色创建为所需权限集的名称。通过授权适当的角色，可以轻松地为用户帐户付与所需的权限。
要创建角色，请利用CREATE ROLE：
CREATE ROLE 'app_developer', 'app_read', 'app_write';
角色名称与用户帐户名称非常相似，由格式中的用户部分和主机部分组成。主机部分，如果省略，则默认为%。用户和主机部分可以不加引号，除非它们包含分外字符。与帐户名称不同，角色名称的用户部分不能为空。为角色分配权限，利用与为用户分配权限相同的语法实行：
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';
现在假设您最初须要一个开拓职员帐户，两个须要只读访问权的用户以及一个须要读取/写入权限的用户。利用CREATEUSER创建用户：
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';
结合角色所需的读取和写入权限，在GRANT中授权 rw_user1用户读取和写入的角色。
在GRANT授权角色的语法和授权用户的语法不同：有一个ON来区分角色和用户的授权，有ON的为用户授权，而没有ON用来分配角色。由于语法不同，因此不能在同一语句中稠浊分配用户权限和角色。（许可为用户分配权限和角色，但必须利用单独的GRANT语句，每种语句的语法都要与授权的内容相匹配。）
2.2、检讨角色权限
要验证分配给用户的权限，利用 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 |
+------------------------------------------------------------------------------+
2.3、撤消角色或角色权限
正如可以授权某个用户的角色一样，可以从帐户中撤销这些角色：
REVOKE role FROM user;
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角色的其他任何帐户一样。
2.4、删除角色
要删除角色，请利用DROP ROLE：
DROP ROLE 'app_read', 'app_write';
删除角色会从授权它的每个帐户中撤消该角色。
2.5、角色和用户在实际中的运用
假设遗留运用开拓项目在MySQL中的角色涌现之前开始，因此与该项目干系联的所有用户都是直接付与权限（而不是付与角色权限）。个中一个帐户是最初被付与权限的开拓者用户，如下所示：
CREATE USER 'old_app_dev'@'localhost' IDENTIFIED BY 'old_app_devpass';
GRANT ALL ON old_app. TO 'old_app_dev'@'localhost';
如果此开拓职员离开项目，则有必要将权限分配给其他用户，或者项目参与人增多，则可能须要多个用户。以下是办理该问题的一些方法：
不该用角色：变动帐户密码，以便原始开拓职员不能利用它，并让新的开拓职员利用该帐户：
ALTER USER 'old_app_dev'@'localhost' IDENTIFIED BY 'new_password';
利用角色：锁定帐户以防止任何人利用它来连接做事器：
ALTER USER 'old_app_dev'@'localhost' ACCOUNT LOCK;
然后将该帐户视为角色。对付每个新开拓项目的开拓者，创建一个新帐户并付与其原始开拓者帐户：
CREATE USER 'new_app_dev1'@'localhost' IDENTIFIED BY 'new_password';
GRANT 'old_app_dev'@'localhost' TO 'new_app_dev1'@'localhost';
厥后果是将原始开拓者帐户权限分配给新帐户。
MySQL8.0的用户和角色管理也越来越像Oracle了，8.0中有不少新的特性，变革还是很大的，须要DBA不断的学习和测试，更新对MySQL新版的认知，更好地运维MySQL数据库。未来MySQL数据库自治和智能数据库是一定发展趋势，对DBA来说是解放，也是寻衅。
