登陸到mysql，查看進(jìn)程的信息

發(fā)現(xiàn)大量的進(jìn)程的狀態(tài)為 login
原來默認(rèn)的時(shí)候mysql啟動時(shí)是不使用 skip-name-resolve選項(xiàng)的，這樣的話，從其它主機(jī)的連接會比較慢，因?yàn)閙ysql會對這個(gè)ip做dns反向查詢，導(dǎo)致大量的連接處于 login狀態(tài)....
.
解決這個(gè)問題有兩個(gè)辦法

一是加入 skip-name-resolve參數(shù)重啟mysql

二是在 /etc/hosts中加入一句 192.168.0.2 server2 其中 192.168.0.2是新加的服務(wù)器的內(nèi)網(wǎng)ip，server2是新服務(wù)器的主機(jī)名


在mysql客戶端登陸mysql服務(wù)器的登錄速度太慢的解決方案一篇文章中，我介紹了如何通過在my.ini文件(linux下是my.cnf文件)中添加"SKIP-NAME-RESOLVE"的參數(shù)設(shè)置，使得客戶端在登錄服務(wù)器的時(shí)候不通過主機(jī)解析這一關(guān)，直接登陸的方法，以此來提高登錄速度。

這里要介紹一下這種方法的負(fù)面作用，以及不合理的時(shí)機(jī)使用這種方法會引發(fā)的不可發(fā)現(xiàn)的錯誤。

首先，回顧一下在my.ini文件中添加"SKIP-NAME-RESOLVE"參數(shù)來提高訪問速度的原理：

在沒有設(shè)置該參數(shù)的時(shí)候，客戶端在登陸請求發(fā)出后，服務(wù)器要解析請求者是誰，經(jīng)過解析，發(fā)現(xiàn)登錄者是從另外的電腦登錄的，也就是說不是服務(wù)器本機(jī)，那么，服務(wù)器會到mysql.user表中去查找是否有這個(gè)用戶，假設(shè)服務(wù)器IP是192.168.0.1，而客戶機(jī)的IP是192.168.0.2；那么查詢的順序是先找'root'@'192.168.0.2'這個(gè)user是否存在，若存在，則匹配這個(gè)用戶登陸，并加載權(quán)限列表。若沒有該用戶，則查找'root'@'%'這個(gè)用戶是否存在，若存在，則加載權(quán)限列表。否則，登錄失敗。

在設(shè)置了SKIP-NAME-RESOLVE參數(shù)后，客戶端的登錄請求的解析式同上面一樣的，但是在服務(wù)器本機(jī)的解析過程卻發(fā)生了改變：服務(wù)器會把在本機(jī)登錄的用戶自動解析為'root'@'127.0.0.1'；而不是'root'@'localhost'；這樣一來就壞了，因?yàn)槲覀冊诜?wù)器上登錄是為了進(jìn)行一些維護(hù)操作，但是顯然，'root'@'127.0.0.1'這個(gè)用戶是被默認(rèn)為'root'@'%'這個(gè)用戶的，這個(gè)用戶還沒有足夠得權(quán)限去執(zhí)行一些超級管理員'root'@'localhost'才能執(zhí)行的大作。因?yàn)槲捶峙錂?quán)限。

所以結(jié)論是：加入你在服務(wù)器本機(jī)上登錄mysql服務(wù)器的話，要么先取消SKIP-NAME-RESOLVE的參數(shù)設(shè)置，重新啟動服務(wù)器再登陸，設(shè)置完成后，再設(shè)置上該參數(shù)；要么就給'root'@'127.0.0.1'分配超級管理員權(quán)限，但這么做顯然是不明智的，因?yàn)槿魏稳嗽谌魏螜C(jī)器上都可以用這個(gè)用戶執(zhí)行管理員操作，前提是知道了密碼。

我有一次在mysql服務(wù)器上執(zhí)行數(shù)據(jù)庫創(chuàng)建腳本，并同時(shí)創(chuàng)建表、觸發(fā)器、存儲過程等。結(jié)果，總是失敗，經(jīng)過了一上午的折騰，最后發(fā)現(xiàn)時(shí)這個(gè)參數(shù)造成我以'root'@'127.0.0.1'這個(gè)用戶登陸了服務(wù)器，這個(gè)用戶沒有創(chuàng)建觸發(fā)器的權(quán)限。后來，取消了SKIP-NAME-RESOLVE參數(shù)后，執(zhí)行成功，再把該參數(shù)設(shè)置回去。重啟。OK。

所以，在設(shè)置這個(gè)參數(shù)的時(shí)候一定要注意時(shí)機(jī)：先用超級管理員將所有的用戶創(chuàng)建好，再將權(quán)限分配好之后，才設(shè)置這個(gè)參數(shù)生效。

最新評論