mysql SKIP-NAME-RESOLVE 錯誤的使用時機形成用戶權限

新加的一臺服務器，鏈接內網中的一臺mysql服務器的時候，常常出現超時。

登錄到mysql，查看進程的信息
代碼以下:
show processlist;

發現大量的進程的狀態爲 login
原來默認的時候mysql啓動時是不使用 skip-name-resolve選項的，這樣的話，從其它主機的鏈接會比較慢，由於mysql會對這個ip作dns反向查詢，致使大量的鏈接處於 login狀態....
.
解決這個問題有兩個辦法

一是加入 skip-name-resolve參數重啓mysql

二是在 /etc/hosts中加入一句 192.168.0.2 server2 其中 192.168.0.2是新加的服務器的內網ip，server2是新服務器的主機名

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

這裏要介紹一下這種方法的負面做用，以及不合理的時機使用這種方法會引起的不可發現的錯誤。

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

在沒有設置該參數的時候，客戶端在登錄請求發出後，服務器要解析請求者是誰，通過解析，發現登陸者是從另外的電腦登陸的，也就是說不是服務器本機，那麼，服務器會到mysql.user表中去查找是否有這個用戶，假設服務器IP是192.168.0.1，而客戶機的IP是192.168.0.2；那麼查詢的順序是先找'root'@'192.168.0.2'這個user是否存在，若存在，則匹配這個用戶登錄，並加載權限列表。若沒有該用戶，則查找'root'@'%'這個用戶是否存在，若存在，則加載權限列表。不然，登陸失敗。

在設置了SKIP-NAME-RESOLVE參數後，客戶端的登陸請求的解析式同上面同樣的，可是在服務器本機的解析過程卻發生了改變：服務器會把在本機登陸的用戶自動解析爲'root'@'127.0.0.1'；而不是'root'@'localhost'；這樣一來就壞了，由於咱們在服務器上登陸是爲了進行一些維護操做，可是顯然，'root'@'127.0.0.1'這個用戶是被默認爲'root'@'%'這個用戶的，這個用戶尚未足夠得權限去執行一些超級管理員'root'@'localhost'才能執行的大做。由於未分配權限。

因此結論是：加入你在服務器本機上登陸mysql服務器的話，要麼先取消SKIP-NAME-RESOLVE的參數設置，從新啓動服務器再登錄，設置完成後，再設置上該參數；要麼就給'root'@'127.0.0.1'分配超級管理員權限，但這麼作顯然是不明智的，由於任何人在任何機器上均可以用這個用戶執行管理員操做，前提是知道了密碼。

我有一次在mysql服務器上執行數據庫建立腳本，並同時建立表、觸發器、存儲過程等。結果，老是失敗，通過了一上午的折騰，最後發現時這個參數形成我以'root'@'127.0.0.1'這個用戶登錄了服務器，這個用戶沒有建立觸發器的權限。後來，取消了SKIP-NAME-RESOLVE參數後，執行成功，再把該參數設置回去。重啓。OK。

因此，在設置這個參數的時候必定要注意時機：先用超級管理員將全部的用戶建立好，再將權限分配好以後，才設置這個參數生效。