Fixing Poor MySQL Default Configuration Values
原文地址：http://jeremy.zawodny.com/blog/archives/011421.html
[幾句廢話：本人英文很爛，今天很無奈地第一次認真地看英文文檔，很糾結，花了好長時間纔看了那麼一丁點兒，回過頭看，竟又忘記自己剛看的內容了~速度太慢，汗||於是想想試着翻譯並記下來吧，順便大家也給我指出錯誤啊~Thank you~]
我最近一直在積累一些MySQL在大的生產環境會產生問題的默認配置變量。它們都具有相同的特性那就是，一兩次網絡波動就會觸發一些非常不想看到的結果。
max_connect_errors
在MySQL的docs裏看到主機被阻止了，可悲的是，這時沒有辦法去徹底阻止這個檢查。卻不能實現設置變量爲0，你的真正解決方案只有（a）設置一個非常大的值（max_connect-error=1844674407370954751）;(b)臨時運行FLUSH HOSTS命令。
connect_timeout
這跟上面的問題相關，在網絡擁塞的情況下（不管是客戶端或者服務端），剛開始連接可能要花費幾秒才能完成，默認的connect_timeout 時間是5秒。當你被這種情況所牽絆，上面的這個max_connect_errors問題就會很有衝擊力。
爲了避免這種情況，首先可以嘗試設置connect_timeout一個值像15 或 20。並且考慮設置thread_cache_size爲一個非零值。當服務器在非常短的時間週期裏，時常保持高的新連接數，這個設置將幫助改善這種情況。
skip-name-resolve
在默認情況下，MySQL做一個反向DNS查詢對每個過來的連接，這就太糟糕了，似乎不論你有多麼好的基礎設施，在DNS服務器有標誌。 MySQL的主機緩存存在，讓那些查找降到最低值。我曾經見過由於這個原因導致了至今8年的麻煩。當這種情況發生的時候，我只能假定這個主機緩存存在一個bug或分析lib庫。
我建議在/etc/my.cnf裏添加skip-name-resolve來完全跳過個DNS。僅僅用IP地址或你授權的範圍。似乎減緩從DNS服務器的回覆也能幫助你改善connect_timeout的牽絆。試想有2、3臺DNS服務器配置，但是第一個不可用。
slave_net_timeout
當主從數據庫的網絡連接在某種程度上被中斷，任何一方都不能檢測（像防火牆或路由改變），你必須等待直到slave_net_timeout設置的時間過後，從數據數才知道連接錯誤了。它將嘗試再次連接主服務器並且採集哪裏使它停止。這真是太可怕了。
然而，這個默認值是3600秒，整整一個小時！太不好了。
誰會希望他們的從服務器在檢查它們哪裏出問題之前，閒置那麼長時間時間？我覺得任何人都不想要這種結果。
我的建議，如果你處在一個繁忙的環境，設置你的值大約30秒。