MySQL性能優化系列-02參數調優

若是咱們須要挖掘正式生產環境上MySQL數據庫服務的性能潛力，那麼對MySQL數據庫服務中的默認參數進行更改就是必需要作的事情。

在進行配置修改以前，咱們能夠先看看當前MySQL數據庫特別是InnoDB引擎的工做狀態：

# 經過執行如下命令，咱們能夠查看當前InnoDB引擎的工做狀態
show engine innodb status;

執行後能夠獲得相似以下的執行結果：

MySQL主要性能參數

innodb_log_file_size：單個日誌文件的大小不宜太小，例如設置爲500MB。因爲InnoBD引擎對日誌文件採用順序寫的操做方式，因此沒必要擔憂日誌文件的操做消耗比數據文件操做更多的性能。

innodb_log_files_in_group：該參數控制了文件組中日誌文件的總數。設置爲2-5的範圍都不會有太大影響。更重要的是讀者應該清楚innodb_log_file_size * innodb_log_files_in_group就是InnoDB引擎在磁盤上可用日誌空間的總大小。

innodb_log_buffer_size：這個參數決定了InnoDB引擎可以使用的日誌內存空間。只要沒有相似插入blob類型數據的操做（也不建議有這樣的操做），這個內存空間都不須要設置得太大。5MB-10MB是一個推薦的設置值，不過這個參數仍是要和innodb_flush_log_at_trx_commit參數配合使用。

innodb_flush_log_at_trx_commit：該參數決定了InnoDB完成一個事務日誌操做後，向磁盤進行持久化的寫入策略。建議設置爲2。

• innodb_flush_log_at_trx_commit = 0時，InnoDB將按照1秒鐘爲單位向磁盤寫入這個階段全部已完成的事務日誌信息。這時innodb_log_buffer_size的值就不能太小，由於在一個同步週期內若是待刷新的日誌超過了innodb_log_buffer_size設置的大小，InnoDB就會強制執行同步操做。這裏的寫入成功並非說寫入到Linux操做系統的Page Cache中就算成功，而是須要等待操做系統真正寫到了物理磁盤上的通知。這意味着即便InnoDB Buffer Pool中的數據操做是成功的，可是一旦數據庫系統異常崩潰，那麼業務系統將會丟失前1秒內寫入的數據：由於沒有磁盤介質上的日誌就沒法在異常重啓後恢復數據信息。

• innodb_flush_log_at_trx_commit = 1時，InnoDB按照完成一個日誌操做就向磁盤寫入日誌信息的方式來工做（執行一個事務就寫入一個事務日誌）。一樣，這裏的寫入成功一樣是要等待操做系統返回真正寫入了物理磁盤的通知，能夠打比方理解爲BIO。

• innodb_flush_log_at_trx_commit = 2時，InnoDB按照完成一個日誌操做就向磁盤寫入日誌信息的方式來工做。可是，這種工做模式下InnoDB不會等待操做系統返回物理磁盤上寫入成功的通知，就會繼續工做，能夠理解爲NIO或MMF。實際上這個時候，數據通常還存在於Linux操做系統的cache memory區塊中，因此這種模式下最好使用帶有日誌功能的文件系統，而且確認開啓了文件系統的日誌功能。

innodb_buffer_pool_size：這個參數調整分配給InnoDB引擎使用的可用數據內存區域的大小。實際上這個數據區域不止包括了本文中一直強調的Page Cache區域，它還有不少數據區域。例如InnoDB中用來進行查詢排序的Sort Buffer區域。建議的設置大小是MySQL數據庫所在服務器上物理總內存的60%——80%（文件系統的Cache Memory/Buffer Memory等其它程序還要使用）。8GB的物理服務器可設置6GB的InnoDB Buffer Pool可用內存區域。注意，當MySQL數據庫啓動時並非馬上就會佔據全部數據區域。

innodb_buffer_pool_instances：咱們常常說起到innodb_buffer_pool_size參數以及它的含義，這個參數值在生產環境下通常設置得都比較大（例如4GB、8GB、12GB、24GB等等）。可是因爲髒數據刷盤的週期性，在I/O性能強勁的物理機器上可能就會存在I/O間歇性低谷，爲了將I/O操做一直保持在必定的工做效能上，也爲了發揮CPU的計算性能，InnoDB引擎容許將innodb_buffer_pool劃分爲多個獨立的運行實例，當InnoDB須要讀取新的Page時，它們會按照必定的算法被分配到某個獨立運行的buffer pool instance中。這些buffer pool instance有各自獨立的LRU算法隊列、獨立計算髒頁比例，而且獨立進行髒頁刷新。innodb_buffer_pool_instances參數在具備較高I/O性能而且具備較大innodb_buffer_pool_size設定值的物理設備上可以對I/O性能產生很是明顯的影響。若是您採用的是固態磁盤或者磁盤陣列做爲MySQL服務器的硬件層存儲介質，那麼建議1-2GB的innodb_buffer_pool就分配一個獨立的運行實例（這樣算下來12GB的buffer pool能夠設置6-12個運行實例）。但若是您只是使用的機械磁盤又或者innodb_buffer_pool_size的值並不大，那麼將innodb_buffer_pool_instances參數設置爲1就能夠了。實例個數沒有絕對值，須要根據測試狀況而定。

innodb_io_capacity：該參數控制着InnoDB Buffer Pool數據內存區域進行磁盤同步時每次能夠同步的髒頁數量。在磁盤I/O性能不足時，若是innodb_io_capacity參數值過大就會形成I/O阻塞，而且形成InnoDB引擎性能較大的下降。但若是您使用的是固態硬盤或者RAID磁盤陣列,就能夠將innodb_io_capacity參數默認的200設置大一些，例如設置成500——800）。

innodb_adaptive_flushing：該參數必定要打開，on，保證髒頁的同步週期由InnoDB引擎根據實時I/O性能狀況自行控制同步頻率（實際上只有兩種頻率：1秒或者10秒）。

innodb_max_dirty_pages_pct：該參數默認爲75，通常狀況下無需更改。

innodb_io_capacity_max：表示當髒頁數量在InnoDB Buffer Pool內存中的比例超過了innodb_max_dirty_pages_pct參數設置的上限後，就按照innodb_io_capacity_max設置的髒頁數量強制進行髒頁的刷新（建議採用默認值便可）。

可是設想一下這個問題：什麼狀況下最可能使髒頁在內存中的佔比超過上限呢？固然是InnoDB引擎的事務不斷快速執行，而且I/O性能又不足以快速完成同步。這時InnoDB引擎將中止事務的執行，而且進行強制刷新。因此，當問題真正發生時innodb_io_capacity_max參數設置得再大也不可能解決I/O擁堵的問題，反而可能使問題更嚴重。

 

MySQL其餘參數

innodb_page_size：該參數決定了InnoDB引擎中每一頁的大小。每個page包含多條row數據，更大的page size意味着內存中存儲的每頁信息有更多的數據條數。因爲文件系統和底層硬件設置的結構，因此該值都爲4KB的整數倍（默認值爲16KB，可選值爲4KB、8KB、16KB）。注意若是您須要更改這個參數值，那麼就必須在MySQL數據庫初始化啓動時，就加入到my.cnf配置文件中。不然一旦建立了用戶數據表，再對這個參數進行修改，MySQL數據庫就會報錯。

innodb_read_io_threads：該參數設置InnoDB數據庫中的負責從磁盤上讀取數據的線程數量，另外這些線程還負責在預讀選項開啓時承擔起預讀的工做任務。innodb_read_io_threads的建議值爲CPU的內核數量。

innodb_write_io_threads：該參數設置InnoDB數據庫中負責將髒頁同步到磁盤上的線程數量。innodb_write_io_threads的建議值爲CPU的內核數量。

innodb_read_ahead_threshold：該參數表示InnoDB引擎中的順序預讀閥值。在buffer pool中的page也有一個組織結構：64個page組成一個extent結構。當InnoDB發如今一個extent結構中**已經連續讀取**N個page，那麼InnoDB會接着將另外64 - N個後續的page讀入到buffer pool中。順序預讀在「連續讀」性能較高的硬件設備上，對性能的影響很是小。因此若是讀者使用了I/O性能比較強勁的固態磁盤環境或者磁盤陣列環境，則建議直接關閉該功能（設置爲0便可）。

innodb_random_read_ahead：該參數表示是否開啓隨機預讀，默認是關閉的。

innodb_flush_neighbors：既然InnoDB引擎提供Page的預讀功能，固然就提供預寫功能。該參數表示當Buffer Pool中的髒頁被同步到磁盤時，是否一塊兒刷新和這個髒頁臨近的頁信息。該參數在I/O性能比較強勁的固態磁盤環境或者磁盤陣列環境下，對性能提高並不明顯。因此建議在這樣的狀況下直接關閉這個功能（設置爲0便可）。

sort_buffer_size：該參數對數據庫引擎的查詢性能，特別是有對結果進行排序要求的查詢性能影響很是大。

join_buffer_size：該參數對數據庫引擎的查詢性能，特別是有各類join鏈接要求的查詢性能影響很是大。

binlog_cache_size：在MySQL數據庫中處理InnoDB層存在「重作日誌」之外，在數據庫管理層還有一個獨立工做的二進制日誌模塊。這個日誌模塊的工做方式和「重作日誌」的工做方式類似，它們採用的辦法都是在內存中進行日誌數據變動，而後再按照必定的策略週期性/直接同步到磁盤上。binlog_cache_size參數設置的就是可供二進制日誌在內存中進行暫存的空間大小。須要注意的是：binlog_cache_size和innodb_buffer_pool_size不一樣的是，binlog_cache_size的大小以MySQL數據庫的客戶端鏈接爲單位。也就是說MySQL數據庫會爲兩個獨立的數據庫客戶端鏈接分別分配獨立運行的binlog cache空間。正式環境的數據庫中爲每個數據庫鏈接設置的binlog cache空間不須要太大，固然這還要考慮實際的客戶端請求頻度和數據類型，還要考慮下面將介紹的sync_binlog參數設定。該參數建議的幾個設置值爲：32768（32KB爲默認值，沒有特別的要求能夠保留該設置）、65536（64KB）、131072（128KB）、262144（KB）、524288（512KB）、1048576（1MB）之內。

sync_binlog：在MySQL數據庫中除了InnoDB的「重作日誌」須要同步之外，二進制日誌也須要進行同步。這個參數是指MySQL數據庫在內存中進行X次二進制日誌操做後，就將內存中的二進制日誌同步到磁盤中。

一組生產參數的範例

如下是一組能夠在配置有固態硬盤和磁盤陣列的正式MySQL數據庫環境下使用的配置項參考，主要是爲讀者總結InnoDB引擎中與I/O性能相關的重要參數。讀者在進行參數配置時，仍須要按照本身團隊的生產環境狀況，對配置項進行調整（這些參數信息都在MySQL數據庫的my.cnf主配置文件中進行設置）。

# 設置單個日誌文件的大小爲500MB
innodb_log_file_size = 524288000

# 設置日誌文件組中有兩個日誌文件
innodb_log_files_in_group = 2

# 設置日誌內存區域爲10MB
innodb_log_buffer_size = 10485760

# 設置日誌數據同步策略爲「2」
innodb_flush_log_at_trx_commit = 2

# 設置buffer pool的大小爲8GB
innodb_buffer_pool_size = 8G

# 設置正常狀況下每一次髒頁到磁盤的同步數量爲800個
# （固然讀者要肯定磁盤I/O性可以用，不然改大這個值有害無益）
innodb_io_capacity = 800

# 打開InnoDB提供的自監控頻率
innodb_adaptive_flushing = on

# 髒頁強制刷新策略
innodb_max_dirty_pages_pct = 75
innodb_io_capacity_max = 2000

# 設置InnoDB的buffer pool區域一共有8個獨立運行的實例
innodb_buffer_pool_instances = 8

# 設置每個數據頁「page」的大小爲16KB。爲4KB的整數倍
innodb_page_size = 16384

# 設置每次二進制日誌操做都提交到文件系統的Cache中
sync_binlog = 0

# 也可設置二進制日誌在內存區域每操做1000次後，就進行磁盤同步
#sync_binlog = 1000

# 關閉順序預讀
# 使用了I/O性能比較強勁的固態磁盤環境或者磁盤陣列環境，則建議直接關閉該功能
innodb_read_ahead_threshold = 0

# 關閉隨機讀
innodb_random_read_ahead = off

# 關閉臨近寫
# 使用了I/O性能比較強勁的固態磁盤環境或者磁盤陣列環境，則建議直接關閉該功能
innodb_flush_neighbors = 0
 

配置完成後，能夠經過如下命令查看當前MySQL數據庫和InnoDB引擎中相關的配置參數（爲節約篇幅，已省去一部分查詢結果）：