背景：

新项目上线，Data Warehouse 的同事要从Mysql 的SLAVE 库上抽取数据。其中一项任务是授予读取数据库的权限。

没想到这个简单的操作也引发了一些意外。

在只读用户增加权限后，修改了密码。导致原来的账户不可用，结果导致数据抽取失败。从而人为导致了一次生产事故。

模拟一下场景：

1. 授予emp001读取test库的权限。session1:

mysql> GRANT SELECT ON test.* TO 'emp001'@'192.168.0.93' IDENTIFIED BY 'pass001';

Query OK, 0 rows affected (0.05 sec)

mysql> flush privileges;

Query OK, 0 rows affected (0.05 sec)

2.用emp001用户可以正常连接数据库。session2:

$mysql -uemp001 -ppass001 -h 192.168.0.93

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 3

Server version: 5.5.37 MySQL Community Server (GPL)

mysql> show databases;

+--------------------+

| Database           |

+--------------------+

| information_schema |

| test               |

+--------------------+

2 rows in set (0.00 sec)

mysql> exit

3.新增加emp001用户访问cream库的权限.回到session1：

mysql> GRANT SELECT ON cream.* TO 'emp001'@'192.168.0.93' IDENTIFIED BY 'emp001.Cream';

Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;

Query OK, 0 rows affected (0.00 sec)[ 数据库使用菜鸟一枚，只会最基本的select。最近碰到一个mysql对某select语句使用索引不当而导致的性能问题，颇有意思，故记之索引，是对数据库操作性能最息息相关的一个

4.用emp001访问cream数据库。session3:

$mysql -uemp001 -pemp001.Cream -h 192.168.0.93

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 4

Server version: 5.5.37 MySQL Community Server (GPL)

到此为止，你能看出这个操作有什么问题吗？现在已经可以正常访问数据库了，应该不会有什么问题吧？

于是下班回家去了......

晚上原来的用户开始抽取数据，悲剧开始了......

5.在用emp001和密码pass001访问数据库，失败。session5：

$mysql -uemp001 -ppass001 -h 192.168.0.93

ERROR 1045 (28000): Access denied for user'emp001'@'192.168.0.93'(using password: YES)

原因是我们给相同的用户增加权限的时候，修改了密码。导致原来的密码不可用。

结论:Mysql中给相同的用户变更授权的时候，如果修改了密码，将会导致原来的密码不可用。最好给指定的用户分配指定的权限。