MySQL配置文件 my.cnf 詳解

MySQL配置文件

[client]
port = 3306  
socket = /var/lib/mysql/mysql.sock


[mysql]
#這個配置段設置啓動MySQL服務的條件;在這種情況下,no-auto-rehash確保這個服務啓動得比較快。
no-auto-rehash


[mysqld]
user = mysql  
port = 3306  
socket = /var/lib/mysql/mysql.sock  
basedir = /usr/local/mysql  
datadir = /data/mysql/data/  
open_files_limit = 10240


back_log = 600  
#在MYSQL暫時停止響應新請求之前,短時間內的多少個請求可以被存在堆棧中。如果系統在短時間內有很多連接,則需要增大該參數的值,該參數值指定到來的TCP/IP連接的監聽隊列的大小。默認值80。


max_connections = 3000  
#MySQL允許最大的進程連接數,如果經常出現Too Many Connections的錯誤提示,則需要增大此值。默認151


max_connect_errors = 6000  
#設置每個主機的連接請求異常中斷的最大次數,當超過該次數,MYSQL服務器將禁止host的連接請求,直到mysql服務器重啓或通過flush hosts命令清空此host的相關信息。默認100


external-locking = FALSE  
#使用–skip-external-locking MySQL選項以避免外部鎖定。該選項默認開啓


max_allowed_packet = 32M  
#設置在網絡傳輸中一次消息傳輸量的最大值。系統默認值 爲4MB,最大值是1GB,必須設置1024的倍數。


#sort_buffer_size = 2M  
# Sort_Buffer_Size 是一個connection級參數,在每個connection(session)第一次需要使用這個buffer的時候,一次性分配設置的內存。
#Sort_Buffer_Size 並不是越大越好,由於是connection級的參數,過大的設置+高併發可能會耗盡系統內存資源。例如:500個連接將會消耗 500*sort_buffer_size(8M)=4G內存
#Sort_Buffer_Size 超過2KB的時候,就會使用mmap() 而不是 malloc() 來進行內存分配,導致效率降低。 系統默認2M,使用默認值即可


#join_buffer_size = 2M  
#用於表間關聯緩存的大小,和sort_buffer_size一樣,該參數對應的分配內存也是每個連接獨享。系統默認2M,使用默認值即可


thread_cache_size = 300  
#默認38
# 服務器線程緩存這個值表示可以重新利用保存在緩存中線程的數量,當斷開連接時如果緩存中還有空間,那麼客戶端的線程將被放到緩存中,如果線程重新被請求,那麼請求將從緩存中讀取,如果緩存中是空的或者是新的請求,那麼這個線程將被重新創建,如果有很多新的線程,增加這個值可以改善系統性能.通過比較 Connections 和 Threads_created 狀態的變量,可以看到這個變量的作用。設置規則如下:1GB 內存配置爲8,2GB配置爲16,3GB配置爲32,4GB或更高內存,可配置更大。


#thread_concurrency = 8  
#系統默認爲10,使用10先觀察
# 設置thread_concurrency的值的正確與否, 對mysql的性能影響很大, 在多個cpu(或多核)的情況下,錯誤設置了thread_concurrency的值, 會導致mysql不能充分利用多cpu(或多核), 出現同一時刻只能一個cpu(或核)在工作的情況。thread_concurrency應設爲CPU核數的2倍. 比如有一個雙核的CPU, 那麼thread_concurrency的應該爲4; 2個雙核的cpu, thread_concurrency的值應爲8


query_cache_size = 64M  
#在MyISAM引擎優化中,這個參數也是一個重要的優化參數。但也爆露出來一些問題。機器的內存越來越大,習慣性把參數分配的值越來越大。這個參數加大後也引發了一系列問題。我們首先分析一下 query_cache_size的工作原理:一個SELECT查詢在DB中工作後,DB會把該語句緩存下來,當同樣的一個SQL再次來到DB裏調用時,DB在該表沒發生變化的情況下把結果從緩存中返回給Client。這裏有一個關建點,就是DB在利用Query_cache工作時,要求該語句涉及的表在這段時間內沒有發生變更。那如果該表在發生變更時,Query_cache裏的數據又怎麼處理呢?首先要把Query_cache和該表相關的語句全部置爲失效,然後在寫入更新。那麼如果Query_cache非常大,該表的查詢結構又比較多,查詢語句失效也慢,一個更新或是Insert就會很慢,這樣看到的就是Update或是Insert怎麼這麼慢了。所以在數據庫寫入量或是更新量也比較大的系統,該參數不適合分配過大。而且在高併發,寫入量大的系統,建議把該功能禁掉。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章