mysql 5.5版本 my.cnf參數配置

MySQL 5.5.13
參數說明：
[client]
character-set-server = utf8
port    = 3306
socket  = /data/mysql/3306/mysql.sock
[mysqld]
character-set-server = utf8
user    = mysql
port    = 3306
socket  = /data/mysql/3306/mysql.sock
basedir = /usr/local/webserver/mysql
datadir = /data/mysql/3306/data
log-error = /data/mysql/3306/mysql_error.log
pid-file = /data/mysql/3306/mysql.pid
# table_cache 參數設置表高速緩存的數目。每一個鏈接進來，都會至少打開一個表緩存。#所以， table_cache 的大小應與 max_connections 的設置有關。例如，對於 200 個#並行運行的鏈接，應該讓表的緩存至少有 200 × N ，這裏 N 是應用能夠執行的查詢#的一個聯接中表的最大數量。此外，還須要爲臨時表和文件保留一些額外的文件描述符。
# 當 Mysql 訪問一個表時，若是該表在緩存中已經被打開，則能夠直接訪問緩存；若是#尚未被緩存，可是在 Mysql 表緩衝區中還有空間，那麼這個表就被打開並放入表緩#衝區；若是表緩存滿了，則會按照必定的規則將當前未用的表釋放，或者臨時擴大表緩存來存放，使用表緩存的好處是能夠更快速地訪問表中的內容。執行 flush tables 會#清空緩存的內容。通常來講，能夠經過查看數據庫運行峯值時間的狀態值 Open_tables #和 Opened_tables ，判斷是否須要增長 table_cache 的值（其中 open_tables 是當#前打開的表的數量， Opened_tables 則是已經打開的表的數量）。即若是open_tables接近table_cache的時候，而且Opened_tables這個值在逐步增長，那就要考慮增長這個#值的大小了。還有就是Table_locks_waited比較高的時候，也須要增長table_cache。
open_files_limit = 10240
table_cache = 512
#非動態變量，須要重啓服務
# 指定MySQL可能的鏈接數量。當MySQL主線程在很短的時間內接收到很是多的鏈接請求，該參數生效，主線程花費很短的時間檢查鏈接而且啓動一個新線程。back_log參數的值指出在MySQL暫時中止響應新請求以前的短期內多少個請求能夠被存在堆棧中。若是系統在一個短期內有不少鏈接，則須要增大該參數的值，該參數值指定到來的TCP/IP鏈接的偵聽隊列的大小。不一樣的操做系統在這個隊列大小上有它本身的限制。試圖設定back_log高於你的操做系統的限制將是無效的。默認值爲50。對於Linux系統推薦設置爲小於512的整數。
back_log = 600
#MySQL容許最大鏈接數
max_connections = 5000
#能夠容許多少個錯誤鏈接
max_connect_errors = 6000
#使用–skip-external-locking MySQL選項以免外部鎖定。該選項默認開啓
external-locking = FALSE
# 設置最大包,限制server接受的數據包大小，避免超長SQL的執行有問題 默認值爲16M，當MySQL客戶端或mysqld服務器收到大於max_allowed_packet字節的信息包時，將發出「信息包過大」錯誤，並關閉鏈接。對於某些客戶端，若是通訊信息包過大，在執行查詢期間，可能會遇到「丟失與MySQL服務器的鏈接」錯誤。默認值16M。
#dev-doc: http://dev.mysql.com/doc/refman/5.5/en/packet-too-large.html
max_allowed_packet = 32M
# Sort_Buffer_Size 是一個connection級參數，在每一個connection（session）第一次須要使用這個buffer的時候，一次性分配設置的內存。
#Sort_Buffer_Size 並非越大越好，因爲是connection級的參數，過大的設置+高併發可能會耗盡系統內存資源。例如：500個鏈接將會消耗 500*sort_buffer_size(8M)=4G內存
#Sort_Buffer_Size 超過2KB的時候，就會使用mmap() 而不是 malloc() 來進行內存分配，致使效率下降。
#技術導讀 http://blog.webshuo.com/2011/02/16/mysql-sort_buffer_size/
#dev-doc: http://dev.mysql.com/doc/refman/5.5/en/server-parameters.html
#explain select*from table where order limit；出現filesort
#屬重點優化參數
sort_buffer_size = 8M
#用於表間關聯緩存的大小
join_buffer_size = 1M
# 服務器線程緩存這個值表示能夠從新利用保存在緩存中線程的數量,當斷開鏈接時若是緩存中還有空間,那麼客戶端的線程將被放到緩存中,若是線程從新被請求，那麼請求將從緩存中讀取,若是緩存中是空的或者是新的請求，那麼這個線程將被從新建立,若是有不少新的線程，增長這個值能夠改善系統性能.經過比較 Connections 和 Threads_created 狀態的變量，能夠看到這個變量的做用
thread_cache_size = 300
# 設置thread_concurrency的值的正確與否, 對mysql的性能影響很大, 在多個cpu(或多核)的狀況下，錯誤設置了thread_concurrency的值, 會致使mysql不能充分利用多cpu(或多核), 出現同一時刻只能一個cpu(或核)在工做的狀況。thread_concurrency應設爲CPU核數的2倍. 好比有一個雙核的CPU, 那麼thread_concurrency的應該爲4; 2個雙核的cpu, thread_concurrency的值應爲8
#屬重點優化參數
thread_concurrency = 8
# 對於使用MySQL的用戶，對於這個變量你們必定不會陌生。前幾年的MyISAM引擎優化中，這個參數也是一個重要的優化參數。但隨着發展，這個參數也爆露出來一些問題。機器的內存愈來愈大，人們也都習慣性的把之前有用的參數分配的值愈來愈大。這個參數加大後也引起了一系列問題。咱們首先分析一下 query_cache_size的工做原理：一個SELECT查詢在DB中工做後，DB會把該語句緩存下來，當一樣的一個SQL再次來到DB裏調用時，DB在該表沒發生變化的狀況下把結果從緩存中返回給Client。這裏有一個關建點，就是DB在利用Query_cache工做時，要求該語句涉及的表在這段時間內沒有發生變動。那若是該表在發生變動時，Query_cache裏的數據又怎麼處理呢？首先要把Query_cache和該表相關的語句所有置爲失效，而後在寫入更新。那麼若是Query_cache很是大，該表的查詢結構又比較多，查詢語句失效也慢，一個更新或是Insert就會很慢，這樣看到的就是Update或是Insert怎麼這麼慢了。因此在數據庫寫入量或是更新量也比較大的系統，該參數不適合分配過大。並且在高併發，寫入量大的系統，建系把該功能禁掉。
#重點優化參數（主庫 增刪改-MyISAM）
query_cache_size = 512M
#指定單個查詢可以使用的緩衝區大小，缺省爲1M
query_cache_limit = 2M
#默認是4KB，設置值大對大數據查詢有好處，但若是你的查詢都是小數據查詢，就容易形成內存碎片和浪費
#查詢緩存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%
#若是查詢緩存碎片率超過20%，能夠用FLUSH QUERY CACHE整理緩存碎片，或者試試減少query_cache_min_res_unit，若是你的查詢都是小數據量的話。
#查詢緩存利用率 = (query_cache_size – Qcache_free_memory) / query_cache_size * 100%
#查詢緩存利用率在25%如下的話說明query_cache_size設置的過大，可適當減少;查詢緩存利用率在80%以上並且Qcache_lowmem_prunes > 50的話說明query_cache_size可能有點小，要不就是碎片太多。
#查詢緩存命中率 = (Qcache_hits – Qcache_inserts) / Qcache_hits * 100%
query_cache_min_res_unit = 2k
default-storage-engine = MyISAM
#限定用於每一個數據庫線程的棧大小。默認設置足以知足大多數應用
thread_stack = 192K
# 設定默認的事務隔離級別.可用的級別以下:
# READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE
# 1.READ UNCOMMITTED-讀未提交2.READ COMMITTE-讀已提交3.REPEATABLE READ -可重複讀4.SERIALIZABLE -串行
transaction_isolation = READ-COMMITTED
# tmp_table_size 的默認大小是 32M。若是一張臨時表超出該大小，MySQL產生一個 The table tbl_name is full 形式的錯誤，若是你作不少高級 GROUP BY 查詢，增長 tmp_table_size 值。
tmp_table_size = 246M
max_heap_table_size = 246M
#索引緩存大小: 它決定了數據庫索引處理的速度，尤爲是索引讀的速度
key_buffer_size = 512M
# MySql讀入緩衝區大小。對錶進行順序掃描的請求將分配一個讀入緩衝區，MySql會爲它分配一段內存緩衝區。read_buffer_size變量控制這一緩衝區的大小。若是對錶的順序掃描請求很是頻繁，而且你認爲頻繁掃描進行得太慢，能夠經過增長該變量值以及內存緩衝區大小提升其性能。
read_buffer_size = 4M
# MySql的隨機讀（查詢操做）緩衝區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySql會首先掃描一遍該緩衝，以免磁盤搜索，提升查詢速度，若是須要排序大量數據，可適當調高該值。但MySql會爲每一個客戶鏈接發放該緩衝空間，因此應儘可能適當設置該值，以免內存開銷過大。
read_rnd_buffer_size = 16M
#批量插入數據緩存大小，能夠有效提升插入效率，默認爲8M
bulk_insert_buffer_size = 64M
# MyISAM表發生變化時從新排序所需的緩衝
myisam_sort_buffer_size = 128M
# MySQL重建索引時所容許的最大臨時文件的大小 (當 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE).
# 若是文件大小比此值更大,索引會經過鍵值緩衝建立(更慢)
myisam_max_sort_file_size = 10G
# 若是一個表擁有超過一個索引, MyISAM 能夠經過並行排序使用超過一個線程去修復他們.
# 這對於擁有多個CPU以及大量內存狀況的用戶,是一個很好的選擇.
myisam_repair_threads = 1
#自動檢查和修復沒有適當關閉的 MyISAM 表
myisam_recover
interactive_timeout = 120
wait_timeout = 120
innodb_data_home_dir = /data/mysql/3306/data
#表空間文件 重要數據
innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend
#這個參數用來設置 InnoDB 存儲的數據目錄信息和其它內部數據結構的內存池大小，相似於Oracle的library cache。這不是一個強制參數，能夠被突破。
innodb_additional_mem_pool_size = 16M
# 這對Innodb表來講很是重要。Innodb相比MyISAM表對緩衝更爲敏感。MyISAM能夠在默認的 key_buffer_size 設置下運行的能夠，然而Innodb在默認的 innodb_buffer_pool_size 設置下卻跟蝸牛似的。因爲Innodb把數據和索引都緩存起來，無需留給操做系統太多的內存，所以若是隻須要用Innodb的話則能夠設置它高達 70-80% 的可用內存。一些應用於 key_buffer 的規則有 — 若是你的數據量不大，而且不會暴增，那麼無需把 innodb_buffer_pool_size 設置的太大了
innodb_buffer_pool_size = 512M
#文件IO的線程數，通常爲 4，可是在 Windows 下，能夠設置得較大。
innodb_file_io_threads = 4
# 在InnoDb核心內的容許線程數量.
# 最優值依賴於應用程序,硬件以及操做系統的調度方式.
# 太高的值可能致使線程的互斥顛簸.
innodb_thread_concurrency = 8
# 若是將此參數設置爲1，將在每次提交事務後將日誌寫入磁盤。爲×××能，能夠設置爲0或2，但要承擔在發生故障時丟失數據的風險。設置爲0表示事務日誌寫入日誌文件，而日誌文件每秒刷新到磁盤一次。設置爲2表示事務日誌將在提交時寫入日誌，但日誌文件每次刷新到磁盤一次。
innodb_flush_log_at_trx_commit = 2
#此參數肯定些日誌文件所用的內存大小，以M爲單位。緩衝區更大能提升性能，但意外的故障將會丟失數據.MySQL開發人員建議設置爲1－8M之間
innodb_log_buffer_size = 16M
#此參數肯定數據日誌文件的大小，以M爲單位，更大的設置能夠提升性能，但也會增長恢復故障數據庫所需的時間
innodb_log_file_size = 128M
#爲提升性能，MySQL能夠以循環方式將日誌文件寫到多個文件。推薦設置爲3M
innodb_log_files_in_group = 3
#推薦閱讀 http://www.taobaodba.com/html/221_innodb_max_dirty_pages_pct_checkpoint.html
# Buffer_Pool中Dirty_Page所佔的數量，直接影響InnoDB的關閉時間。參數innodb_max_dirty_pages_pct 能夠直接控制了Dirty_Page在Buffer_Pool中所佔的比率，並且幸運的是innodb_max_dirty_pages_pct是能夠動態改變的。因此，在關閉InnoDB以前先將innodb_max_dirty_pages_pct調小，強制數據塊Flush一段時間，則可以大大縮短 MySQL關閉的時間。
innodb_max_dirty_pages_pct = 90
# InnoDB 有其內置的死鎖檢測機制，能致使未完成的事務回滾。可是，若是結合InnoDB使用MyISAM的lock tables 語句或第三方事務引擎,則InnoDB沒法識別死鎖。爲消除這種可能性，能夠將innodb_lock_wait_timeout設置爲一個整數值，指示 MySQL在容許其餘事務修改那些最終受事務回滾的數據以前要等待多長時間(秒數)
innodb_lock_wait_timeout = 120
#獨享表空間（關閉）
innodb_file_per_table = 0
#start mysqld with –slow-query-log-file=/data/mysql/3306/slow.log
slow_query_log
long_query_time = 1
replicate-ignore-db = mysql
replicate-ignore-db = test
replicate-ignore-db = information_schema
#配置從庫上的更新操做是否寫二進制文件，若是這臺從庫，還要作其餘從庫的主庫，那麼就須要打這個參數，以便從庫的從庫可以進行日誌同步這個參數要和—logs-bin一塊兒使用
log-slave-updates
log-bin = /data/mysql/3306/binlog/binlog
binlog_cache_size = 4M
#STATEMENT,ROW,MIXED
# 基於SQL語句的複製(statement-based replication, SBR)，基於行的複製(row-based replication, RBR)，混合模式複製(mixed-based replication, MBR)。相應地，binlog的格式也有三種：STATEMENT，ROW，MIXED。
binlog_format = MIXED
max_binlog_cache_size = 64M
max_binlog_size = 1G
relay-log-index = /data/mysql/3306/relaylog/relaylog
relay-log-info-file = /data/mysql/3306/relaylog/relaylog
relay-log = /data/mysql/3306/relaylog/relaylog
expire_logs_days = 30
skip-name-resolve
#master-connect-retry = 10
slave-skip-errors = 1032,1062,126,1114,1146,1048,1396
server-id = 1
[mysqldump]
quick
max_allowed_packet = 32M
[myisamchk]
key_buffer_size = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
interactive-timeout