明天和朋友聊了聊技术的事情，聊到BAT上面的一些高大上的系统和设计，相比总是会有些差别，不过像那样体量的公司知识沉淀很深，所以才能做好我们力所能及的事情，把它细化做好，也是一种进步和改进。
假如你老是认为自己的环境受限，有各类KPI或则是成本的审视，做事情从下往起来促进很难，那些都是实际的困难，好多公司都是存在这样的问题的。在资源受限方面，我尤其苦恼，举个有意思的小反例，假如我收到一条报案，提示数据库表空间不足了，那就添加一个数据文件呗，结果数据库层面的空间问题解决了，而马上会收到一个系统空间不足的报案，见到这些情况，你自己感受，心情肯定是很复杂的。
明天遇到的一个案例比较非常，是关于MySQL登陆的，数据库环境是5.6版本。
>selectversion();
+—————--+
|version()|
+—————--+
|5.6.23-72.1-log|
+—————--+
1rowinset(0.01sec)明天朋友问我一个问题，想让我瞧瞧某个数据库用户的权限问题，我登陆到服务器端以后，一切都很顺利。
#mysql
Loggingtofile’/home/mysql/query.log’
WelcometotheMySQLmonitor.Commandsendwith;org.
YourMySQLconnectionidis52625
Serverversion:5.6.23-72.1-logPerconaServer(GPL),Release72.1,Revision0503478一切都很正常，之后我打算瞧瞧联接到数据库的线程情况。
>showprocesslist;
ERROR1227(42000):Accessdenied;youneed(atleastoneof)thePROCESSprivilege(s)forthisoperation居然抛出了这个奇怪的错误，假如想查看数据字典中的信息，也被严禁了。
>selectuser,hostfrommysql.user;
ERROR1142(42000):SELECTcommanddeniedtouser”@’linuxcool’fortable’user’这个时侯就很郁闷了，我堂堂的root用户居然登陆不了MySQL了，别说给朋友排除故障linux命令行，自己都登陆不了了。
带着疑惑，我查看了errorlog,居然没有发觉哪些相关的异常信息。
这个问题该如何继续往下走linux mysql 登录命令，假如要做改动，影响到现有的测试用户就不好了，即便是测试环境，重启服务之类的还是要和开发朋友充分沟通以后能够动手，毕竟我是帮忙查看这个环境，更不能随意改动了。
对于这个问题让我有些恐惧的时侯，我想到之前还真给自己留了一道侧门，那就是之前帮她们处理问题的时侯，我在自己的服务器端设定了一个用户，来测试数据库的联接情况，没想到这样一个无心之举就成了剖析这个问题的最后一把锁匙。
很快，我从安全认证的中控顾客端登陆到了这台MySQL服务器，联接数有100多个。一边感慨自己的英明，一边速速剖析问题。
这个数据库中有10个左右的数据库用户，大体是这样的内容，做了更改。
>selectuser,hostfrommysql.user;
+—————-+—————————--+
|user|host|
+—————-+—————————--+
|cloud_test|%|
|cloudcs_app|%|
|root|%|
|cloud_test|10.127.138.107|
|root|10.127.138.107|
||linuxcool|
|jeanron|test_user%|
+—————-+—————————--+查看showprocess的信息，见到是用户是root
|52629|root|linuxcool
+——-+—————-+————查看root@linuxcool的权限，居然没有。
>showgrantsforroot@’linuxcool’;
ERROR1141(42000):Thereisnosuchgrantdefinedforuser’root’onhost’linuxcool’这个时侯我们停一下，在这个场景中，系统mysql命令直接联接进来的是root@linuxcool吗？从错误日志来看不是，而从线程信息来看是，所以我们须要进一步剖析一下，问题在那里。
尽管服务端直接mysql命令登陆后linux系统怎么样，查看不了线程情况，查看不了数据字典，并且showgrants这个命令是可以的。
>showgrants;
+————————
|Grantsfor@linuxcool
+————————
|GRANTUSAGEON*.*TO”@’linuxcool’可以看下来，登陆的用户是”@’linuxcool’,而不是root@’linuxcool’，这个环境中没有配置root@’linuxcool’用户。
之后再度查看mysql.user的情况，才会发觉下边的配置比较非常。root使用了笼统的域名形式，容许不同的IP来访问，而另外有一条记录是指定的IP。
|root|%|
|root|10.127.138.107|
||linuxcool|这个才能说明哪些呢，也就是说使用root@linuxcool的疗效和root@’%’是类似的。而这个”@linuxcool目前是默认的联接形式，须要说的是，在这个配置下是优先的。
我们初始化一个mysql环境后，通常mysql.user的内容是这样的，例如一个5.7的环境。
mysql>selectuser,hostfrommysql.user;
+———--+———--+
|user|host|
+———--+———--+
|mysql.sys|linuxcool|
|root|linuxcool|
+———--+———--+
2rowsinset(0.00sec)默认的联接方法是root@’linuxcool’
而在里面的场景中linux mysql 登录命令，没有root@’linuxcool’的配置，就优先使用了”@’linuxcool’这个用户。
为何会有这个问题呢，和开发朋友沟通以后，定位剖析，发觉原先之前这个服务器的IP发生过变化。后来开发朋友自己也做了一些更改和配置，就是现今的情况了。
对于这些情况如何修补呢，我的看法是删掉匿名用户，服务端不启用密码，即root@’linuxcool’,而顾客端联接则使用域名解析的方法，并且对开发朋友不开放root权限，所以我们删掉root@’%’用户。
删掉匿名用户”@’linuxcool’
>dropuser”@linuxcool;
删掉最高权限的root用户，不对外提供任意的权限访问。
dropuserroot@’%’;更改那种IP发生变化的服务器配置，更改为linuxcool
>updatemysql.usersethost=’linuxcool’whereuser=’root’andhost=’10.127.138.107′;设置密码为空，最后使用flushprivileges即可。
这样一来，我们的预期疗效就达到了，使用mysql登陆即可。
>showgrants;
+—————————-
|Grantsforroot@linuxcool
