MySQL優化之配置文件
前言
- 通常默認的 my.cnf 配置文件無法發揮出 MySQL 最高的性能，所以需要根據不同的硬件進行優化，配置文件的優化也是重點，下面是物理內存爲 32G 的數據庫優化參數，具體從全局、二進制日誌、主從、innodb、myisam 幾個方面優化，僅供參考。
優化配置如下
1. default-time-zone=+8:00
#默認 mysql 使用的是系統時區，修改爲北京時間，也就是所說的東八區。
2. interactive_timeout = 120
#服務器關閉交互式連接前等待活動的秒數。
3. wait_timeout = 120
#服務器關閉非交互連接之前等待活動的秒數。
4. open_files_limit = 10240
#MySQL 服務器打開文件句柄數限制。
5. group_concat_max_len = 102400
#mysql 默認的拼接最大長度爲 1024 個字節，由於 1024 個字節會出現不夠用的情況， 根據實際情況進行修改。
6. user=mysql
#使用 mysql 用戶運行。character-set-server=utf8 init_connect='SET NAMES utf8' #設置字符集爲 utf8
7. back_log = 600
#在 MySQL 暫時停止響應新請求之前，短時間內的多少個請求可以被存在堆棧中。如果系統在短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的 TCP/IP 連接的監聽隊列的大小。默認值 50。
8. max_connections = 5000
#MySQL 允許最大的進程連接數，如果經常出現 Too Many Connections 的錯誤提示， 則需要增大此值。
9. max_connect_errors = 6000
#設置每個主機的連接請求異常中斷的最大次數，當超過該次數，MySQL 服務器將禁止host 的連接請求，直到 mysql 服務器重啓或通過 flush hosts [命令](http://www.linuxyw.com/a/Linuxmingling/)清空此 host 的相關信息。
10. table_cache = 1024
#指示表調整緩衝區大小。它設置表高速緩存的數目。每個連接進來，都會至少打開一個表緩存。因此，table_cache 的大小應與 max_connections 的設置有關。例如，對於 200 個並行運行的連接，應該讓表的緩存至少有 200 × N 。這裏 N 是應用可以執行的查詢的一個連接中表的最大數量。此外，還需要爲臨時表和文件保留一些額外的文 件描述符。 當 [Mysql](http://www.linuxyw.com/a/Mysql/) 訪問一個表時，如果該表在緩存中已經被打開，則可以直接訪問緩存；如果還沒有被緩存，但是在 Mysql 表緩衝區中還有空間，那麼這個表就被打開並放入表緩衝區；如果表緩存滿了，則會按照一定的規則將當前未用的表釋放，或者臨時擴大 表 緩 存 來 存 放 ， 使 用 表 緩 存 的 好 處 是 可 以 更 快 速 地 訪 問 表 中 的 內 容 。 執行 flush tables 會清空緩存的內容。一般來說，可以通過 show status 命令查看[數據](http://www.linuxyw.com/a/shujuku/)庫運行峯值時間的狀態值 Open_tables 和 Opened_tables ， 判斷是否需要增加 table_cache 的 值 （ 其 中 open_tables 是 當 前 打 開 的 表 的 數量， Opened_tables 則是已經打開的表的數量）。即如果 open_tables 接近 table_cache 的時候，並且 Opened_tables 這個值在逐步增加，那就要考慮增加這個值的大小了。還有就是 Table_locks_waited 比較高的時候，也需要增加 table_cache。
11. table_open_cache = 2048
指定表高速緩存的大小。每當 MySQL 訪問一個表時，如果在表緩衝區中還有空間，該表就被打開並放入其中，這樣可以更快地訪問表內容。
12. max_heap_table_size = 256M
這個變量定義了用戶可以創建的內存表(memory table)的大小.這個值用來計算內存表的最大行數值。這個變量支持動態改變，即 set @max_heap_table_size=#
但是對於已經存在的內存表就沒有什麼用了，除非這個表被重新創建(create table) 或者修改(alter table)或者 truncate table。服務重啓也會設置已經存在的內存表爲全局
max_heap_table_size 的值。
13. external-locking = false
#使用 skip-external-locking MySQL 選項以避免外部鎖定。該選項默認開啓。
14. max_allowed_packet = 32M
#設置在網絡傳輸中一次消息傳輸量的最大值。系統默認值 爲 1MB，最大值是 1GB，必須設置 1024 的倍數。
15. sort_buffer_size = 512M
# Sort_Buffer_Size 是一個 connection 級參數，在每個 connection（session）第一次需要使用這個 buffer 的時候，一次性分配設置的內存。Sort_Buffer_Size 並不是越大越好，由於是 connection 級的參數，過大的設置+高併發可能會耗盡系統內存資源。
16. join_buffer_size = 8M
#用於表間關聯緩存的大小，和 sort_buffer_size 一樣，該參數對應的分配內存也是每個連接獨享。
17. thread_cache_size = 300
# 服務器線程緩存這個值表示可以重新利用保存在緩存中線程的數量,當斷開連接時如果緩存中還有空間,那麼客戶端的線程將被放到緩存中,如果線程重新被請求，那麼請求將從緩存中讀取,如果緩存中是空的或者是新的請求，那麼這個線程將被重新創建,如果有很多新 的 線 程 ， 增 加 這 個 值 可 以 改 善 系 統 性 能 . 通 過 比較 Connections 和 Threads_created 狀態的變量，可以看到這個變量的作用。設置規則如下：1GB 內存配置爲 8，2GB 配置爲 16，3GB 配置爲 32，4GB 或更高內存，可配置更大。
18. thread_concurrency = 8
# 設置 thread_concurrency 的值的正確與否, 對 mysql 的性能影響很大, 在多個[cp](http://www.linuxyw.com/a/wenjianguanli/20130505/203.html)u(或多核)的情況下，錯誤設置了 thread_concurrency 的值, 會導致 mysql 不能充分利用多 cpu(或多核), 出現同一時刻只能一個 cpu(或核)在工作的情況。thread_concurrency 應設爲 CPU 核數的 2 倍. 比如有一個雙核的 CPU, 那麼 thread_concurrency 的應該爲4; 2 個雙核的 cpu, thread_concurrency 的值應爲 8。
19. query_cache_size = 512M
# 對於使用 MySQL 的用戶，對於這個變量大家一定不會陌生。前幾年的 MyISAM 引擎優化中，這個參數也是一個重要的優化參數。但隨着發展，這個參數也爆露出來一些問題。機器的內存越來越大，人們也都習慣性的把以前有用的參數分配的值越來越大。這個參數加大 後也引發了一系列問題。我們首先分析一下 query_cache_size 的工作原理：一個 SELECT 查詢在 DB 中工作後，DB 會把該語句緩存下來，當同樣的一個 SQL 再次來到 DB 裏調用時， DB 在該表沒發生變化的情況下把結果從緩存中返回給 Client。這裏有一個關建點，就是 DB 在利用 Query_cache 工作時，要求該語句涉及的表在這段時間內沒有發生變更。那如果該表在發生變更時，Query_cache 裏的數據又怎麼處理呢？首先要把 Query_cache 和該表相關的語句全部置爲失效，然後在寫入更新。那麼如果 Query_cache 非常大，該表的查詢結構又比較多，查詢語句失效也慢，一個更新或是 Insert 就會很慢，這樣看到的就是 Update 或是Insert 怎麼這麼慢了。所以在數據庫寫入量或是更新量也比較大的系統，該參數不適合分配過大。而且在高併發，寫入量大的系統，建議把該功能禁掉。
20. query_cache_limit = 4M
#指定單個查詢能夠使用的緩衝區大小，缺省爲 1M。
21．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% 。
22. default-storage-engine = innodb
#默認引擎，現在一般都是 innodb 引擎表居多。
23. thread_stack = 192K
#設置MYSQL 每個線程的堆棧大小，默認值足夠大，可滿足普通操作。可設置範圍爲 128K 至 4GB，默認爲 192KB。
24. transaction_isolation = READ-COMMITTED
# 設定默認的事務隔離級別，READ COMMITTEE 是讀已提交
25. tmp_table_size = 256M
# tmp_table_size 的默認大小是 32M。如果一張臨時表超出該大小，MySQL 產生一個 The table tbl_name is full 形式的錯誤，如果執行很多高級 GROUP BY 查詢，增加 tmp_table_size 值。如果超過該值，則會將臨時表寫入磁盤。
26. key_buffer_size = 1024M
#批定用於索引的緩衝區大小，增加它可以得到更好的索引處理性能。
27. read_buffer_size = 2M
# MySql 讀入緩衝區大小。對錶進行順序掃描的請求將分配一個讀入緩衝區，MySql 會爲它分配一段內存緩衝區。read_buffer_size 變量控制這一緩衝區的大小。如果對錶的順序掃描請求非常頻繁，並且你認爲頻繁掃描進行得太慢，可以通過增加該變量值以及內存 緩衝區大小提高其性能。和 sort_buffer_size 一樣，該參數對應的分配內存也是每個連接獨享。
28. read_rnd_buffer_size = 256M
# MySql 的隨機讀（查詢操作）緩衝區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySql 會首先掃描一遍該緩衝，以避免磁盤搜索，提高查詢速度，如果需要排序大量數據，可適當調高該值。但 MySql 會爲每個客戶連接發放該緩衝空間，所以應儘量適當設置該值，以避免內存開銷過大。
29. bulk_insert_buffer_size = 64M
#批量插入數據緩存大小，可以有效提高插入效率，默認爲 8M。
30. skip-name-resolve
#禁止域名解析，包括主機名，所以當授權的時候使用 IP 地址。
31. ft_min_word_len = 1
#從 Mysql 4.0 開始就支持全文索引功能，但是 Mysql 默認的最小索引長度是 4。如果是英文默認值是比較合理的，但是中文絕大部分詞都是 2 個字符，這就導致小於 4 個字的詞都不能被索引，Mysql 全文索引是專門爲了解決模糊查詢提供的，可以對整篇文章預先按照詞進行索引，搜索效率高，能夠支持百萬級的數據檢索。
- 下面幾個參數時關於 MySQL 二進制日誌文件的優化。
32. log-bin=mysql-bin
#打開 MySQL 二進制功能。
33. binlog_cache_size = 4M
#在事務過程中容納二進制日誌 SQL 語句的緩存大小。二進制日誌緩存是服務器支持事務存儲引擎並且服務器啓用了二進制日誌(—log-bin 選項)的前提下爲每個客戶端分配的內存，注意，是每個 Client 都可以分配設置大小的 binlogcache 空間。可以通過 MySQL 的以下兩個狀態變量來判斷當前的 binlog_cache_size 的狀況： Binlog_cache_use 和Binlog_cache_disk_use。
34. max_binlog_cache_size = 128M
#但是所代表的是 binlog 能夠使用的最大 cache 內存大小。當我們執行多語句事務的時候 ， max_binlog_cache_size 如 果 不 夠 大 的 話 ， 系 統 可 能 會 報 出“Multi-statementtransactionrequiredmorethan'max_binlog_cache_size'bytesofstorag e”的錯誤。
35. max_binlog_size = 1G
#Binlog 日誌最大值，一般來說設置爲 512M 或者 1G，但不能超過 1G。該大小並不能非常嚴格控制Binlog 大小，尤其是當到達Binlog 比較靠近尾部而又遇到一個較大事務的時候，系統爲了保證事務的完整性，不可能做切換日誌的動作，只能將該事務的所有 SQL 都記錄進入當前日誌，直到該事務結束。這一點和 Oracle 的 Redo 日誌有點不一樣，因爲 Oracle 的Redo 日誌所記錄的是數據文件的物理位置的變化，而且裏面同時記錄了 Redo 和 Undo 相關的信息，所以同一個事務是否在一個日誌中對 Oracle 來說並不關鍵。而 MySQL 在 Binlog 中所記錄的是數據庫邏輯變化信息，MySQL 稱之爲 Event，實際上就是帶來數據庫變化的 DML 之類的 Query 語句。
36. sync_binlog=1
#在 MySQL 中系統默認的設置是 sync_binlog=0，也就是不做任何強制性的磁盤刷新指令，這時候的性能是最好的，但是風險也是最大的。因爲一旦系統 Crash，在 binlog_cache 中的所有 binlog 信息都會被丟失。而當設置爲“1”的時候，是最安全但是性能損耗最大的設置。因爲當設置爲 1 的時候，即使系統 Crash，也最多丟失 binlog_cache 中未完成的一個事務，對實際數據沒有任何實質性影響。從以往經驗和相關測試來看，對於高併發事務的系統來說，“sync_binlog”設置爲 0 和設置爲 1 的系統寫入性能差距可能高達 5 倍甚至更多。
37. binlog_format=mixed
#默認使用 statement 模式，基於 SQL 語句的複製，另外一種是基於行的複製，爲提升效率，可以將以上兩種模式的混合使用，一般的複製使用 STATEMENT 模式保存 binlog，對於 STATEMENT 模式無法複製的操作使用 ROW 模式保存 binlog，MySQL 會根據執行的 SQL 語句選擇日誌保存方式。
38. expire_logs_days = 7
二進制日誌只留存最近 7 天，不用人工手動刪除。
39. log-slave-updates
#這條參數只讀主從架構適用，當從庫 log_slave_updates 參數沒有開啓時，從庫的binlog 不會記錄來源於主庫的操作記錄。只有開啓 log_slave_updates，從庫 binlog 纔會記錄主庫同步的操作日誌。
40. slow_query_log
#打開慢查詢日誌
41. slow_query_log_file=slow.log
#慢查詢日誌文件位置
42. long_query_time = 2
#記錄超過 2 秒的 SQL 查詢
- 關於引擎是 innodb 的優化如下：
43. innodb_additional_mem_pool_size = 64M
#這個參數用來設置 InnoDB 存儲的數據目錄信息和其它內部數據結構的內存池大小， 類似於 Oracle 的 lib[rar](http://www.linuxyw.com/a/tiaoyou/20130521/421.html)y cache。這不是一個強制參數，可以被突破。
44. innodb_buffer_pool_size = 20480M
# 這對 Innodb 表來說非常重要。Innodb 相比 MyISAM 表對緩衝更爲敏感。MyISAM 可以在 默 認 的 key_buffer_size 設 置 下 運 行 的 可 以 ， 然 而 Innodb 在 默 認的 innodb_buffer_pool_size 設置下卻跟蝸牛似的。由於 Innodb 把數據和索引都緩存起來， 無需留給操作系統太多的內存， 因此如果只需要用 Innodb 的話則可以設置它高達 70-80% 的可用內存。一些應用於 key_buffer 的規則有 — 如果你的數據量不大， 並且不會暴增，那麼無需把 innodb_buffer_pool_size 設置的太大了。
45. innodb_data_file_path = ibdata1:1024M:autoextend
#表空間文件 重要數據
46. innodb_file_io_threads = 4
#文件 IO 的線程數，一般爲 4，但是在 Windows 下，可以設置得較大。
47. innodb_thread_concurrency = 8
#服務器有幾個 CPU 就設置爲幾，建議用默認設置，一般爲 8。
48. innodb_write_io_threads = 8
# InnoDB 使用後臺線程處理數據頁上寫 I/O（輸入輸出）請求的數量。一般設置爲 CPU 核數，比如 CPU 是 2 顆 8 核的，可以設置爲 8。
49. innodb_read_io_threads = 8
# InnoDB 使用後臺線程處理數據頁上讀 I/O（輸入輸出）請求的數量。一般設置爲 CPU 核數，比如 CPU 是 2 顆 8 核的，可以設置爲 8。
50. innodb_flush_log_at_trx_commit = 2
# 如果將此參數設置爲 1，將在每次提交事務後將日誌寫入磁盤。爲提供性能，可以設置爲 0 或 2，但要承擔在發生故障時丟失數據的風險。設置爲 0 表示事務日誌寫入日誌文件，而日誌文件每秒刷新到磁盤一次。設置爲 2 表示事務日誌將在提交時寫入日誌，但日誌文件每次刷新到磁盤一次。
51. innodb_log_buffer_size = 16M
# 此參數確定些日誌文件所用的內存大小，以 M 爲單位。緩衝區更大能提高性能，但意外的故障將會丟失數據.MySQL 開發人員建議設置爲 1－8M 之間
52. innodb_log_file_size = 256M
# 此參數確定數據日誌文件的大小，以 M 爲單位，更大的設置可以提高性能，但也會增加恢復故障數據庫所需的時間
53. innodb_log_files_in_group = 3
# 爲提高性能，MySQL 可以以循環方式將日誌文件寫到多個文件。
54．innodb_file_per_table = 1
# 獨享表空間（關閉）
55. 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 關閉的時間。
56. innodb_lock_wait_timeout = 120
# InnoDB 有其內置的死鎖檢測機制，能導致未完成的事務回滾。但是，如果結合InnoDB 使用 MyISAM 的 lock tables 語句或第三方事務引擎,則 InnoDB 無法識別死鎖。爲消除這種可能性，可以將 innodb_lock_wait_timeout 設置爲一個整數值，指示 MySQL 在允許其他事務修改那些最終受事務回滾的數據之前要等待多長時間(秒數)。
57. innodb_open_files = 8192
#innodb 打開文件句柄數。
- 關於引擎是 myisam 的優化如下：
58. myisam_sort_buffer_size = 128M
# MyISAM 表發生變化時重新排序所需的緩衝
59. myisam_max_sort_file_size = 10G
# MySQL 重 建 索 引 時 所 允 許 的 最 大 臨 時 文 件 的 大小 (當 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE)。如果文件大小比此值更大,索引會通過鍵值緩衝創建(更慢)
60. myisam_repair_threads = 1
# 如果一個表擁有超過一個索引, MyISAM 可以通過並行排序使用超過一個線程去修復。這對於擁有多個 CPU 以及大量內存情況的用戶,是一個很好的選擇。
61. myisam_recover
#自動檢查和修復沒有適當關閉的 MyISAM 表