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怎麼這麼慢了。所以在資料庫寫入量或是更新量也比較大的系統，該引數不適合分配過大。而且在高併發，寫入量大的系統，建議把該功能禁掉。