本文適合初步接觸者做一些參考，老手就不用這樣去操作了，希望有不對的多多指教。

重要強調！本人并不是專業DBA，難免有錯誤或遺漏的地方，還請大家給予指正。操作前做好備份。

重要強調！本人并不是專業DBA，難免有錯誤或遺漏的地方，還請大家給予指正。操作前做好備份。

重要強調！本人并不是專業DBA，難免有錯誤或遺漏的地方，還請大家給予指正。操作前做好備份。

先說一下，這里通過寶塔來操作的，開始前先來兩張圖

圖一

圖二

1、活動/峰值連接數

 (圖1)中當前活動的連接為1個，自MySQL服務啟動以來，最高連接數為54；當最高連接數接近或等于(圖2)中的max_connections時，應適當增加max_connections，需要注意的是，不要一下子增加過多，建議每次增加50，觀察一段時間，不夠再繼續增加。

2、線程緩存命中率

(圖1)中線程緩存命中率為99.78%，若這個值小于90%，建議適當增加(圖2)中的thread_cache_size，建議每次增加8。

3、索引命中率

(圖1)中索引命中率為99.50%，若這個值小于95%，建議適當增加(圖2)中的key_buffer_size，建議每次增加64，需要說明的是，若您的數據庫使用的是Innodb引擎，可忽略這個選項

4、Innodb索引命中率 

(圖1)中Innodb索引命中率為100%，若這個值小于95%，建議適當增加(圖2)中的innodb_buffer_pool_size，建議每次增加64，需要說明的是，若您的數據庫沒有使用Innodb引擎，可忽略這個選項

5、查詢緩存命中率

MySQL查詢緩存是個比較受爭議的功能，個人建議當你有在使用redis、memcached等緩存軟件時，在(圖2)中將query_cache_size設為0可以將其關閉，當你沒有使用緩存軟件，有多余的內存使用，且數據庫瓶頸明顯存在時，可以嘗試開啟查詢緩存，這是個非常依賴數據表結構及SQL語句優化的功能，若數據表結構和SQL語句都針對查詢緩存進行過優化，它的效果還是很不錯的。

6、創建臨時表到磁盤

(圖1)中創建臨時表到磁盤的比例是0.42%，這說明大部分臨時表創建到內存了，不會過多增加磁盤IO的開銷，建議，當比例大于2%時適當增加(圖1)中的tmp_cache_size，建議每次增加32，當比例大于60%時，放棄吧，有些開源程序并沒有專門優化過SQL語句，所以在運行過程中會開啟大量臨時表，加多少緩存都是不夠用的。

7、已打開的表

當(圖1)中的已打開的表接近或等于(圖2)中的table_open_cache時，可以適當增加table_open_cache，但若設置過大可能導致您的程序頻繁中斷MySQL連接，建議在1024以內，最大不要超過2048。

8、沒有使用索引的量、沒有使用索引的JOIN量

 若不為0，就檢查下數據表索引吧，其實只要沒有瘋漲，比如一天增漲幾千，一般可以忽略，必竟優化索引還是程序員或DBA去干比較合適。

9、排序后的合并次數

如果這個值在緩慢增張，建議適當增加(圖2)中的sort_buffer_size，建議每次增加512，但最大不要超過8192，如果這個值一直在瘋漲，增加sort_buffer_size也沒用，就放棄這個選項吧，這個鍋還是給程序開發者背。

10、鎖表次數

如果服務器CPU開銷不大的情況下，瘋狂鎖表，建議你將所有數據表轉換成innodb，記得轉換前備份哦。

11、優化方案

這個是我們根據內存大小給的一個推薦優化方案，僅是建議僅用于基礎參考值，還是要根據實據情況來調整每一個配置項。

希望大家通過自己的不斷觀察，不斷調整，找到最適合自己的，關于調優，沒有最好的參數，只有最適合自己的。加油。