MySQL使用root用户给某用户分配权限报错：Access denied for user 'root'@'%' to database 'xxx'

这个错误相信很多人都遇到过，一般我们想到的第一点就是没有授权，然后一条命令走起：

grant all on xxxx.* to 'root'@'%' identified by 'password' with grant option;   

然后flush，接着继续执行了之前的操作，发现：Access denied for user 'root'@'%' to database 'xxx'
这时候有点懵懵的，也许你在执行了grant操作后不会遇到这个提示了，所以我今天说的这个问题并不是这个问题。我先还原一下问题场景。

问题场景

我们项目要上线二级测试环境了，所以新增了一个mysql用户AA,需要将数据库DB-A的操作权限分配给AA用户，然后用root用户执行了分配操作后，报错：Access denied for user 'root'@'%' to database 'AA'。
这时候对root用户执行了grant all操作

然后继续对AA用户分配DB-A库的操作权限，然后依旧报错。
所以，并不是文章开头提到的问题，所以才想着现在回来记录一下。遇到一个坑，填一个坑~~

那么是什么导致这个问题出现的，明明root用户已经拥有了所有权限，为什么给某个用户分配一些权限的时候还是报错root没有权限，root都没权限…，root这个用户就像神一般的存在，没有它干不了的事，可是为什么依旧报错。
这个时候，想到去查看一下，mysql 的进程，以及mysql的root用户的相关进程，看下是什么情况。

解决

直接查看root用户的相关进程：

当然你也可以直接用Navicat管理工具直接查看


这个时候会发现，上面的进程列表中，有多个root的进程，并且host不同，这时候CTO在旁边说到，这么多进程有可能就是导致root分配权限失败的原因。
仔细想一下，刚开时候的时候对root用户执行了grant all操作，也进行了flush，但是这个时候注意，因为当时候我们有多个同事同时以root用户连接了MySQL，当前已经存在了多个不同host的root进程，所以在对root用户grant all操作刷新后，由于多个host的root用户连接，并不知道哪个root进程执行了grant all操作，所以在对AA用户分配库权限的时候报错root没有权限。
这个时候将所有的root相关进程都给结束掉：

SELECT concat('KILL ',id,';') FROM information_schema.processlist WHERE user='root';

用Navicat管理工具直接手动删除也可以。
这时候再次将数据库DB-A的操作权限分配给AA用户，很好，一切正常。
以上的操作，熟悉Navicat的同学都可以直接使用管理工具界面华操作。
问题解决了，不过问题的原因只是我的想法，欢迎留言解惑。