MySQL配置參數優化
mysql服務性能優化之my.cnf配置說明詳解
硬件：內存16G
#在MYSQL暫時停止響應新請求之前，短時間內的多少個請求可以被存在堆棧中。如果系統在短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的監聽隊列的大小。默認值50。
max_connections = 2000
#MySQL允許最大的進程連接數，如果經常出現Too Many Connections的錯誤提示，則需要增大此值。
max_connect_errors = 6000
#設置每個主機的連接請求異常中 斷的最大次數，當超過該次數，MYSQL服務器將禁止host的連接請求，直到mysql服務器重啟或通過flush hosts命令清空此host的相關信息。
table_open_cache = 2048
#指示表調整緩沖區大小。table_open_cache 參數設置表高速緩存的數目。每個連接進來，都會至少打開一個表緩存。因此， table_open_cache 的大小應與 max_connections 的設置有關。
# 當 Mysql 訪問一個表時，如果該表在緩存中已經被打開，則可以直接訪問緩存；如果#還沒有被緩存，但是在 Mysql 表緩沖區中還有空間，那么這個表就被打開並放入表緩#沖區；如果表緩存滿了，則會按照一定的規則將當前未用的表釋放，或者臨時擴大表緩存來存放，使用表緩存的好處是可以更快速地訪問表中的內容。執行 flush tables 會清空緩存的內容。一般來說，可以通過查看數據庫運行峰值時間的狀態值 Open_tables 和 Opened_tables ，判斷是否需要增加 table_open_cache 的值（其中 open_tables 是當前打開的表的數量， Opened_tables 則是已經打開的表的數量）。即如果open_tables接近table_open_cache的時候，並且Opened_tables這個值在逐步增加，那就要考慮增加這個值的大小了。還有就是Table_locks_waited比較高的時候，也需要增加table_open_cache。
# 注意，不能盲目地把table_open_cache設置成很大的值，設置太大超過了shell的文件描述符(通過ulimit -n查看)，造成文件描述符不足，從而造成性能不穩定或者連接失敗
#比較適合的值：
# Open_tables / Opened_tables >= 0.85
# Open_tables / table_open_cache <= 0.95
external-locking = FALSE
#使用–skip-external-locking MySQL選項以避免外部鎖定。該選項默認開啟
max_allowed_packet = 32M
#設置在網絡傳輸中一次消息傳輸量的最大值。系統默認值 為1MB，最大值是1GB，必須設置1024的倍數。
sort_buffer_size = 1M
# Sort_Buffer_Size 是一個connection級參數，在每個connection（session）第一次需要使用這個buffer的時候，一次性分配設置的內存。
#Sort_Buffer_Size 並不是越大越好，由於是connection級的參數，過大的設置+高並發可能會耗盡系統內存資源。例如：8M的情況下500個連接將會消耗 500*sort_buffer_size(8M)=4G內存
#在Linux上，有256KB和2MB的閾值，較大的值可能會顯著降低內存分配
join_buffer_size = 1M
#用於表間關聯緩存的大小，和sort_buffer_size一樣，該參數對應的分配內存也是每個連接獨享。
#如果join語句不多,不用調整此參數, 如果join語句較多的話, 可將此參數調整到1M, 如果內存充足,還可增大到2M.
thread_cache_size = 300
# 服務器線程緩存這個值表示可以重新利用保存在緩存中線程的數量,當斷開連接時如果緩存中還有空間,那么客戶端的線程將被放到緩存中,如果線程重新被請求，那么請求將從緩存中讀取,如果緩存中是空的或者是新的請求，那么這個線程將被重新創建,如果有很多新的線程，增加這個值可以改善系統性能.通過比較 Connections 和 Threads_created 狀態的變量，可以看到這個變量的作用。設置規則如下：1GB 內存配置為8，2GB配置為16，3GB配置為32，4GB或更高內存，可配置更大。
query_cache_size = 64M
## 對於使用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_limit = 4M
#指定單個查詢能夠使用的緩沖區大小，缺省為1M
query_cache_min_res_unit = 2k
#默認是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%
default-storage-engine = MyISAM
#default_table_type = InnoDB
thread_stack = 192K
#設置MYSQL每個線程的堆棧大小，默認值足夠大，可滿足普通操作。可設置范圍為128K至4GB，默認為192KB。
tmp_table_size = 256M
# tmp_table_size 的默認大小是 32M。如果一張臨時表超出該大小，MySQL產生一個 The table tbl_name is full 形式的錯誤，如果你做很多高級 GROUP BY 查詢，增加 tmp_table_size 值。如果超過該值，則會將臨時表寫入磁盤。
key_buffer_size = 2048M
#批定用於索引的緩沖區大小，增加它可以得到更好的索引處理性能，對於內存在4GB左右的服務器來說，該參數可設置為256MB或384MB。
read_buffer_size = 1M
# MySql讀入緩沖區大小。對表進行順序掃描的請求將分配一個讀入緩沖區，MySql會為它分配一段內存緩沖區。read_buffer_size變量控制這一緩沖區的大小。如果對表的順序掃描請求非常頻繁，並且你認為頻繁掃描進行得太慢，可以通過增加該變量值以及內存緩沖區大小提高其性能。和sort_buffer_size一樣，該參數對應的分配內存也是每個連接獨享。
read_rnd_buffer_size = 16M
# MySql的隨機讀（查詢操作）緩沖區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySql會首先掃描一遍該緩沖，以避免磁盤搜索，提高查詢速度，如果需要排序大量數據，可適當調高該值。但MySql會為每個客戶連接發放該緩沖空間，所以應盡量適當設置該值，以避免內存開銷過大。
bulk_insert_buffer_size = 64M
#批量插入數據緩存大小，可以有效提高插入效率，默認為8M
innodb_additional_mem_pool_size = 16M
#這個參數用來設置 InnoDB 存儲的數據目錄信息和其它內部數據結構的內存池大小，類似於Oracle的library cache。這不是一個強制參數，可以被突破。
innodb_buffer_pool_size = 2048M
# 這對Innodb表來說非常重要。Innodb相比MyISAM表對緩沖更為敏感。MyISAM可以在默認的 key_buffer_size 設置下運行的可以，然而Innodb在默認的 innodb_buffer_pool_size 設置下卻跟蝸牛似的。由於Innodb把數據和索引都緩存起來，無需留給操作系統太多的內存，因此如果只需要用Innodb的話則可以設置它高達 70-80% 的可用內存。一些應用於 key_buffer 的規則有 — 如果你的數據量不大，並且不會暴增，那么無需把 innodb_buffer_pool_size 設置的太大了
innodb_data_file_path = ibdata1:1024M:autoextend
#表空間文件 重要數據, 可以設置多個
innodb_file_io_threads = 4
#文件IO的線程數，一般為 4，但是在 Windows 下，可以設置得較大。
innodb_thread_concurrency = 8
#服務器有幾個CPU就設置為幾
innodb_flush_log_at_trx_commit = 2
# 如果將此參數設置為1，將在每次提交事務后將日志寫入磁盤。為提供性能，可以設置為0或2，但要承擔在發生故障時丟失數據的風險。設置為0表示事務日志寫入日志文件，而日志文件每秒刷新到磁盤一次。設置為2表示事務日志將在提交時寫入日志，但日志文件每次刷新到磁盤一次。
innodb_log_buffer_size = 16M
#此參數確定些日志文件所用的內存大小，以M為單位。緩沖區更大能提高性能，但意外的故障將會丟失數據.MySQL開發人員建議設置為1－8M之間
innodb_log_file_size = 128M
#此參數確定數據日志文件的大小，以M為單位，更大的設置可以提高性能，但也會增加恢復故障數據庫所需的時間
innodb_log_files_in_group = 3
#為提高性能，MySQL可以以循環方式將日志文件寫到多個文件。推薦設置為3M
innodb_max_dirty_pages_pct = 90
# 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_lock_wait_timeout = 120
# InnoDB 有其內置的死鎖檢測機制，能導致未完成的事務回滾。但是，如果結合InnoDB使用MyISAM的lock tables 語句或第三方事務引擎,則InnoDB無法識別死鎖。為消除這種可能性，可以將innodb_lock_wait_timeout設置為一個整數值，指示 MySQL在允許其他事務修改那些最終受事務回滾的數據之前要等待多長時間(秒數)
innodb_file_per_table = 0
#獨享表空間（關閉）