同時在線訪問量繼續增大 對於G內存的服務器明顯感覺到吃力嚴重時甚至每天都會死機 或者時不時的服務器卡一下 這個問題曾經困擾了我半個多月MySQL使用是很具伸縮性的算法因此你通常能用很少的內存運行或給MySQL更多的被存以得到更好的性能
安裝好mysql後配制文件應該在/usr/local/mysql/share/mysql目錄中配制文件有幾個有f f f f不同的流量的網站和不同配制的服務器環境當然需要有不同的配制文件了
一般的情況下f這個配制文件就能滿足我們的大多需要一般我們會把配置文件拷貝到/etc/f 只需要修改這個配置文件就可以了使用mysqladmin variables extendedstatus –u root –p 可以看到目前的參數有３個配置參數是最重要的即key_buffer_sizequery_cache_sizetable_cache
key_buffer_size只對MyISAM表起作用
key_buffer_size指定索引緩沖區的大小它決定索引處理的速度尤其是索引讀的速度一般我們設為M實際上稍微大一點的站點 這個數字是遠遠不夠的通過檢查狀態值Key_read_requests和Key_reads可以知道key_buffer_size設置是否合理比例key_reads / key_read_requests應該盡可能的低至少是::更好（上述狀態值可以使用SHOW STATUS LIKE key_read%獲得） 或者如果你裝了phpmyadmin 可以通過服務器運行狀態看到筆者推薦用phpmyadmin管理mysql以下的狀態值都是本人通過phpmyadmin獲得的實例分析:
這個服務器已經運行了天
key_buffer_size – M
key_read_requests –
key_reads
比例接近: 健康狀況非常好
另外一個估計key_buffer_size的辦法 把你網站數據庫的每個表的索引所占空間大小加起來看看以此服務器為例:比較大的幾個表索引加起來大概M 這個數字會隨著表變大而變大
從開始MySQL提供了查詢緩沖機制使用查詢緩沖MySQL將SELECT語句和查詢結果存放在緩沖區中今後對於同樣的SELECT語句（區分大小寫）將直接從緩沖區中讀取結果根據MySQL用戶手冊使用查詢緩沖最多可以達到%的效率
通過調節以下幾個參數可以知道query_cache_size設置得是否合理
Qcache inserts
Qcache hits
Qcache lowmem prunes
Qcache free blocks
Qcache total blocks
Qcache_lowmem_prunes的值非常大則表明經常出現緩沖不夠的情況同時Qcache_hits的值非常大則表明查詢緩沖使用非常頻繁此時需要增加緩沖大小Qcache_hits的值不大則表明你的查詢重復率很低這種情況下使用查詢緩沖反而會影響效率那麼可以考慮不用查詢緩沖此外在SELECT語句中加入SQL_NO_CACHE可以明確表示不使用查詢緩沖
Qcache_free_blocks如果該值非常大則表明緩沖區中碎片很多query_cache_type指定是否使用查詢緩沖
我設置:
query_cache_size = M
query_cache_type=
得到如下狀態值:
Qcache queries in cache 表明目前緩存的條數
Qcache inserts
Qcache hits 看來重復查詢率還挺高的
Qcache lowmem prunes 有這麼多次出現緩存過低的情況
Qcache not cached
Qcache free memory 目前剩余緩存空間
Qcache free blocks 這個數字似乎有點大 碎片不少
Qcache total blocks
如果內存允許M應該要往上加點
table_cache指定表高速緩存的大小每當MySQL訪問一個表時如果在表緩沖區中還有空間該表就被打開並放入其中這樣可以更快地訪問表內容通過檢查峰值時間的狀態值Open_tables和Opened_tables可以決定是否需要增加table_cache的值如果你發現open_tables等於table_cache並且opened_tables在不斷增長那麼你就需要增加table_cache的值了（上述狀態值可以使用SHOW STATUS LIKE Open%tables獲得）注意不能盲目地把table_cache設置成很大的值如果設置得太高可能會造成文件描述符不足從而造成性能不穩定或者連接失敗
對於有G內存的機器推薦值是－
筆者設置table_cache =
得到以下狀態:
Open tables
Opened tables
雖然open_tables已經等於table_cache但是相對於服務器運行時間來說已經運行了天opened_tables的值也非常低因此增加table_cache的值應該用處不大如果運行了個小時就出現上述值 那就要考慮增大table_cache
如果你不需要記錄進制log 就把這個功能關掉注意關掉以後就不能恢復出問題前的數據了需要您手動備份二進制日志包含所有更新數據的語句其目的是在恢復數據庫時用它來把數據盡可能恢復到最後的狀態另外如果做同步復制( Replication )的話也需要使用二進制日志傳送修改情況
log_bin指定日志文件如果不提供文件名MySQL將自己產生缺省文件名MySQL會在文件名後面自動添加數字引每次啟動服務時都會重新生成一個新的二進制文件此外使用logbinindex可以指定索引文件使用binlogdodb可以指定記錄的數據庫使用binlogignoredb可以指定不記錄的數據庫注意的是binlogdodb和binlogignoredb一次只指定一個數據庫指定多個數據庫需要多個語句而且MySQL會將所有的數據庫名稱改成小寫在指定數據庫時必須全部使用小寫名字否則不會起作用
關掉這個功能只需要在他前面加上#號
#logbin
開啟慢查詢日志( slow query log )
慢查詢日志對於跟蹤有問題的查詢非常有用它記錄所有查過long_query_time的查詢如果需要還可以記錄不使用索引的記錄下面是一個慢查詢日志的例子
開啟慢查詢日志需要設置參數log_slow_querieslong_query_timeslogqueriesnotusingindexes
log_slow_queries指定日志文件如果不提供文件名MySQL將自己產生缺省文件名long_query_times指定慢查詢的阈值缺省是秒logqueriesnotusingindexes是以後引入的參數它指示記錄不使用索引的查詢筆者設置long_query_time=
筆者設置:
sort_buffer_size = M
max_connections=
wait_timeout =
back_log=
read_buffer_size = M
thread_cache=
interactive_timeout=
thread_concurrency =
參數說明:
back_log
要求MySQL能有的連接數量當主要MySQL線程在一個很短時間內得到非常多的連接請求這就起作用然後主線程花些時間(盡管很短)檢查連接並且啟動一個新線程back_log值指出在MySQL暫時停止回答新請求之前的短時間內多少個請求可以被存在堆棧中只有如果期望在一個短時間內有很多連接你需要增加它換句話說這值對到來的TCP/IP連接的偵聽隊列的大小你的操作系統在這個隊列大小上有它自己的限制 Unix listen()系統調用的手冊頁應該有更多的細節檢查你的OS文檔找出這個變量的最大值試圖設定back_log高於你的操作系統的限制將是無效的
max_connections
並發連接數目最大 超過這個值就會自動恢復出了問題能自動解決
thread_cache
沒找到具體說明不過設置為後 天才創建了多個線程 而以前一天就創建了上千個線程 所以還是有用的
thread_concurrency
#設置為你的cpu數目x例如只有一個cpu那麼thread_concurrency=
#有個cpu那麼thread_concurrency=
skipinnodb
#去掉innodb支持
From:http://tw.wingwit.com/Article/program/MySQL/201311/29351.html
