MySQL設置裝備擺設文件my.cnf優化詳解(mysql5.5)。本站提示廣大學習愛好者：（MySQL設置裝備擺設文件my.cnf優化詳解(mysql5.5)）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL設置裝備擺設文件my.cnf優化詳解(mysql5.5)正文
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
