技術標籤：MYSQL

寫入效能優化的一些引數

說完了如何修改和檢視RDS引數，我們接下來看一下一些和寫入效能相關的引數，限於篇幅，我們不能介紹所有的MYSQL引數。

innodb_buffer_pool_size

在MYSQL中buffer pool用來快取表和索引的資料，以便加速對資料的處理。如果在buffer在pool中無法獲取資料（所謂cache miss），那麼就會產生磁碟的隨機IO請求，這會降低處理速度，所以配置一個合適大小的buffer pool對效能至關重要。RDS中innodb_buffer_pool_size會設定為{DBInstanceClassMemory*3/4}。

我們可以通過show engine innodb status \G和SHOW GLOBAL STATUS命令觀察innodb_buffer_pool_size設定是否合適。

通過show engine innodb status \G我們可以看到free buffers、buffer pool hit rate以及evicted without access（資料被載入到buffer pool沒有被訪問前就又被推出buffer pool）。

• 如果較長時間內即使業務高峰期，free buffers都很大，buffer pool hit rate 高於99.5%，evicted without access為0，則innodb_buffer_pool_size可能過量設定了。
• 如果較長時間內尤其業務高峰期，free buffers都很小，buffer pool hit rate 低於99%，evicted without access不為0，則說明innodb_buffer_pool_size設定得太小，需要增大。

show global status where variable_name in (‘Innodb_buffer_pool_read_requests’, ‘Innodb_buffer_pool_reads’); 我們可以關注以下資料，來判斷innodb_buffer_pool_size設定的是否合適。

• innodb_buffer_pool_reads表示InnoDB緩衝池無法滿足的請求數。需要從磁碟中讀取。
• innodb_buffer_pool_read_requests表示從記憶體中邏輯讀取的請求數。
• Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads) * 100 = InnoDB Buffer Pool hit ratio

注意：對於 MySQL 5.7，管理 InnoDB 緩衝池的方式當前存在錯誤https://bugs.mysql.com/bug.php?id=79379。MySQL 5.7 可能將innodb_buffer_pool_size引數的值調整為較大的值，這會導致 InnoDB 緩衝池增長得過大並佔用過多記憶體。此效果會導致 MySQL 資料庫引擎停止執行或阻止 MySQL 資料庫引擎啟動。可用記憶體較少的資料庫例項類更易出現此問題。要解決此問題，請將innodb_buffer_pool_size引數的值設定為innodb_buffer_pool_instances引數值和innodb_buffer_pool_chunk_size引數值的積的倍數。例如，您可以將innodb_buffer_pool_size引數值設定為innodb_buffer_pool_instances引數值和innodb_buffer_pool_chunk_size引數值的積的 8 倍，如以下示例所示。

innodb_buffer_pool_chunk_size = 536870912

innodb_buffer_pool_instances = 4

innodb_buffer_pool_size = (536870912 * 4) * 8 = 17179869184

innodb_log_file_size

在mysql 5.5和5.5以前innodb的logfile最大設定為4GB,在5.6以後的版本中innodb_log_file_size*innodb_log_files_in_group（每個log group中日誌檔案的個數，預設為2）不能超過512GB。innodb的logfile就是事務日誌，用來在mysql 崩潰後的恢復，設定合理的大小對於mysql的效能非常重要。logfile大小對於效能的影響主要體現在checkpoint上，對於 checkpoint的原理可以參考相關的關係資料庫理論，更大的logfile大小可以減少checkpoint的次數，減少disk I/O，但是也會增加崩潰後恢復時間。

在MYSQL RDS預設引數組中，innodb_log_file_size預設值為134,217,728 (大約128 MB)，通常對您的應用來說該數值嫌小。那麼設定多大的logfile合適呢？ 通常我們建議innodb_log_file_size*innodb_log_files_in_group要可以承載我們業務高峰期一個小時的日誌量，我們可以用命令show engine innodb status\G select sleep(60); show engine innodb status\G 計算每分鐘的日誌量，進而確定引數的合適大小。此外，基於Bug #69477，日誌檔案大小應該至少是資料庫中最大的BLOB的大小的十倍。

5.0以上版本的MYSQL也可以通過以下命令去查詢一分鐘內生成日誌的大小：

show global status like ‘Innodb_os_log_written%’;

innodb_io_capacity與innodb_io_capacity_max

innodb_io_capacity決定了innodb後臺任務（譬如從buffer pool重新整理頁面或從change pool合併頁面）每秒可用的IO操作次數（IOPS）。innodb_io_capacity預設值是200，可選範圍100–18,446,744,073,709,551,615，而innodb_io_capacity_max是當重新整理滯後時，後臺任務可以執行的最大IOPS，可選範圍100–18,446,744,073,709,551,615，如果您設定了innodb_io_capacity但沒有設定innodb_io_capacity_max，則innodb_io_capacity_max預設是innodb_io_capacity的兩倍，。

關於這兩個引數，若你真的需要對它進行調整，最好的方法是要了解系統可以支援多大的 IOPS。對於SSD我們可以設定innodb_io_capacity為1000，雖然可以設定很大值，但是innodb_io_capacity一般很少設定超過20000，除非您已經嘗試過較低的值否則不要設定較大的值。

那麼我們如何判斷髒頁重新整理不夠快呢？我們可以通過SHOW GLOBAL STATUS LIKE ‘Innodb_buffer_pool_%’;命令，如下圖所示，髒頁在buffer中的百分比就是Innodb_buffer_pool_pages_dirty/Innodb_buffer_pool_pages_total * 100%

• Innodb_buffer_pool_pages_data和Innodb_buffer_pool_bytes_data: buffer pool中buffer總數。
• Innodb_buffer_pool_pages_dirty和Innodb_buffer_pool_bytes_dirty: buffer pool中髒buffer的數量。
• Innodb_buffer_pool_pages_total: buffer pool總頁數。

如果使用了information_schema，我們也可以通過以下語句來查詢

mysql> SELECT dirty.Value AS 'Dirty Pages', total.Value AS 'Total Pages', ROUND(100*dirty.Value/total.Value, 2) AS 'Dirty Pct' FROM (SELECT VARIABLE_VALUE AS Value FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_total') AS total INNER JOIN (SELECT VARIABLE_VALUE AS Value FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_dirty') AS dirty;
+-------------+-------------+-----------+
| Dirty Pages | Total Pages | Dirty Pct |
+-------------+-------------+-----------+
| 0         | 131072        |      0.00 |
+-------------+-------------+-----------+
1 row in set (0.00 sec)

總之，如果髒頁佔比長時間較高且從監控看IO有較大餘裕，則可調大innodb_io_capacity，但不要一下調整過大，要逐步提高。

innodb_flush_log_at_trx_commit

innodb_flush_log_at_trx_commit定義資料庫寫log buffer到磁碟的頻率以及方式 ，磁碟寫入會影響效能，故而此引數讓您可以在效能和永續性之間做出選擇。

• 如果innodb_flush_log_at_trx_commit設定為0，每秒一次會將log buffer寫入log file（這時資料只是從innodb記憶體到了作業系統的cache，依然沒有進入磁碟）， log file的flush(刷到磁碟)操作也同時進行。該模式下，在事務提交的時候，不會主動觸發寫入磁碟的操作。
• 如果innodb_flush_log_at_trx_commit設定為1，每次事務提交時MySQL都會把log buffer的資料寫入log file，並且flush(刷到磁碟)中去。
• 如果innodb_flush_log_at_trx_commit設定為2，每次事務提交時MySQL都會把log buffer的資料寫入log file.但是flush(刷到磁碟)操作並不會同時進行。該模式下,MySQL會每秒執行一次 flush(刷到磁碟)操作。

當設為0和2的時候，flush操作不能100%保證，所以在崩潰或斷電的時候可能會丟失最後一秒的資料，而1是預設也是最安全的設定，保證commit的資料不會丟失。MYSQL RDS預設 innodb_flush_log_at_trx_commit也是1，這會對效能有消極影響但除非您可以接受丟失資料，否則不建議修改。

sync_binlog

sync_binlog 控制 MySQL server 將 binary log 同步到磁碟的頻率，MYSQL RDS預設設定為最安全的1，但是同樣會對效能有消極影響，除非您可以接受丟失資料，否則不建議修改。

• sync_binlog=0: MySQL不控制binlog的重新整理，由檔案系統自己控制它的快取的重新整理。這時候的效能是最好的，但是風險也是最大的。因為一旦系統崩潰，在binlog_cache中的所有binlog資訊都會被丟失。
• sync_binlog=1: 這是最安全的設定，表示每次事務提交，MySQL都會把binlog刷下去，不過最安全也是效能損耗最大的設定，尤其對高併發的場景sync_binlog設定為0和1之間寫入效能相差會很大，甚至達到5倍之多。
• sync_binlog=N, N是 0 和1以外的正整數: binary log 會在收集N個binary log commit groups 之後同步，同樣在系統崩潰的時候 ，可能會丟失資料，N越大效能越好但同時丟失資料的風險也越大。

tmp_table_size與max_heap_table_size

MYSQL在很多場景譬如UNION操作，子查詢，排序分組操作中都可能會生成temporary table，我們通過EXPLAIN輸出執行計劃的Extra列可以看到SQL是否使用了temporary table。temporary table的最大大小由tmp_table_size與max_heap_table_size其中較小的值決定（MYSQL RDS這兩個引數預設值都是16777216即16M），temporary table在大小未超過上限時建立在記憶體中，一旦超過該上限，temporary table就會自動轉為磁碟上的表，這將增加磁碟IO和消耗的時間。我們可能都遇到過複雜查詢執行很長時間，從show full processlist可以看到copying to tmp table on disk的狀態，這就說明我們的temporary table超過了上限，轉為了磁碟上的表。

我們可以通過命令SHOW GLOBAL STATUS LIKE ‘Created_tmp%’;檢視記憶體和磁碟中temporary table得數量，我們可以通過Created_tmp_disk_tables和Created_tmp_tables瞭解在磁碟中temporary table的比例。

如果您的應用有大量複雜查詢，Created_tmp_disk_tables比例居高不下，IO成為系統瓶頸而記憶體又有較大餘裕，您可以考慮逐步調大tmp_table_size與max_heap_table_size。但是請注意，這會給記憶體帶來壓力，此外，某些場景下，temporary table一定會建立在磁碟而不是記憶體中，譬如：

• 表中存在BLOB或文字列。這包括具有字串值的使用者定義變數，依據列值是二進位制還是非二進位制字串而分別被視為BLOB或文字列。
• 在一個GROUP BY或DISTINCT子句中存在大於512位元組(二進位制字串)或大於512字元(非二進位制字串)的任何字串列。
• 使用UNION或UNION ALL，且選擇列表中存在最大長度大於512(二進位制字串為位元組，非二進位制字串為字元)的任何字串列。
• SHOW列和DESCRIBE語句使用BLOB作為某些列的型別，因此用於結果的臨時表是磁碟上的表

foreign_key_checks與unique_checks

當我們對MYSQL RDS進行大批量資料匯入或載入，尤其涉及大表時，我們可以通過暫時關閉外來鍵和唯一約束檢查來提高插入效能，但是這會帶來潛在的風險，您務必要確保相應的資料一致和唯一性。否則約束檢查不能通過。

我們可以按以下方式進行資料庫匯入：

SET FOREIGN_KEY_CHECKS = 0;
SET UNIQUE_CHECKS = 0;
SET AUTOCOMMIT = 0;
... SQL載入語句 ...
SET foreign_key_checks=1;
SET UNIQUE_CHECKS =1;
commit;

Innodb_read_io_threads 和 Innodb_write_io_threads

innodb_read_io_threadsandinnodb_write_io_threads決定了InnoDB使用多少後臺執行緒來處理各種型別的IO請求。通過這個配置InnoDB可以有更好的擴充套件性，每個後臺程序可以處理256個IO請求，InnoDB希望可以平衡請求的負載。兩個引數有效值範圍是1-64，預設值是4。引數決定後臺程序數，但是linux系統預設會設定innodb_use_native_aio不為0，啟動非同步IO，就會突破引數限制

如果您有高階的IO系統，且在SHOW ENGINE INNODB STATUS的輸出中看到64 × innodb_read_io_threads的pending read requests，那麼提升innodb_read_io_threads的值會對提升效能有幫助。

測試

硬體環境

本次測試將通過sysbench軟體對AWS MYSQL5.6 RDS default引數組以及調整後的引數組進行壓測，比對調優效果。請注意：sysbench測試是用來輔助我們判斷系統性能的一個方法，用您的實際業務進行壓測永遠更有針對性。而且在效能測試中，不同的資源配置（包括測試客戶端，資料庫本身以及網路等），引數配置乃至測試流程都會導致不同的結果，所以進行比對分析永遠要先統一測試環境、流程才有意義。

隨著軟體迭代，本文中描述的測試流程可能需要更新，請讀者把握測試流程和指標含義，在工作中按實際情況進行調整。

本文所用硬體環境如下：

2個sysbench客戶端配置如下：

資料庫配置如下：資料庫開啟了multi-AZ,保證資料庫高可用,但是會對寫入效能有較大影響

引數調整

根據硬體環境以及測試時產生的日誌量，對引數做了針對性調整，有些引數需要資料庫重啟才能生效，請在執行相應測試步驟前確認引數值。

請注意：下面的引數僅僅針對本測試中的硬體環境和測試工作量負載，並不具有普遍性，請讀者理解引數的含義，根據自身環境和工作負載進行相應配置。正如前述，除非您可以接受丟失資料，否則不建議修改innodb_flush_log_at_trx_commit、sync_binlog等引數為了效能而犧牲安全性，所以本次測試沒有對這兩個引數進行修改，如果您有類似需求，可以根據本文提供的方法自行測試。

注意：因為sysbench1.0.18會有大量prepared statement，所以要設定max_prepared_stmt_count為最大值1048576保證測試順利進行，否則初始化時可能遇到錯誤FATAL: MySQL error: 1461 “Can’t create more than max_prepared_stmt_count statements (current value: 16382)”

測試環境準備

在2臺測試客戶端安裝sysbench1.0.18

1.從git中下載sysbench

sudo yum install gcc gcc-c++ autoconf automake make libtool bzr mysql-devel git mysql
git clone https://github.com/akopytov/sysbench.git

2.開啟sysbench目錄

cd sysbench

3.切換到sysbench 1.0.18版本，執行autogen.sh

git checkout 1.0.18
sudo ./autogen.sh

4.編譯

sudo ./configure --prefix=/usr --mandir=/usr/share/man
sudo make
sudo make install

開啟限制

開始測試前，需要在Sysbench客戶端執行 以下配置，告訴Linux kernel可以用所有的CPU cores 去處理 packets（預設只可以用兩個）,且減少cores 之間的context switching. 這兩個設定是為了用更少的Sysbench 客戶端達成吞吐目標.( ffffffff表示使用32個核。請根據實際配置修改，例如實際只有8核，則輸入ff)

sudo sh -c 'for x in /sys/class/net/eth0/queues/rx-*; do echo ff > $x/rps_cpus; done'
sudo sh -c "echo 32768 > /proc/sys/net/core/rps_sock_flow_entries"
sudo sh -c "echo 4096 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt"
sudo sh -c "echo 4096 > /sys/class/net/eth0/queues/rx-1/rps_flow_cnt"
vim /etc/security/limits.conf
*                              soft    nofile  65536
*                              hard    nofile  65536
*                              soft    nproc  65536
*                              hard    nproc  65536

測試流程

只讀負載測試

測試資料注入

首先通過sysbench客戶端在測試資料庫上生成測試表，這裡生成250個表，每個表有行數25000條，您也可以根據您的目標，調整表的數目和大小，請替換<>之中的各種連線資訊，再執行命令，如果您直接從blog拷貝命令請注意格式。後續命令的注意事項相同，將不再贅述

sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-port=<port> --mysql-user=<username> --mysql-password=<password> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --time=600  oltp_read_only prepare

測試

在所有sysbench client同時執行命令模擬負載，每次持續20分鐘，同時從console檢視資料庫CPU，IO，網路等metrics。在這裡我們將通過修改num_threads引數連續測試2*32, 2*64,2*128,2*256多種併發連線的場景。

sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=32 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=20 oltp_read_only run >> <dbname>_read.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=64 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=20 oltp_read_only run >> <dbname>_read.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=128 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=20 oltp_read_only run >> <dbname>_read.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=256 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=20 oltp_read_only run >> <dbname>_read.log

清除測試資料

測試後清除資料命令如下：

sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-port=<port> --mysql-user=<username> --mysql-password=<password> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --time=600  oltp_read_only cleanup

只寫負載測試

資料注入

sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-port=<port> --mysql-user=<username> --mysql-password=<password> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --time=600  oltp_write_only prepare

測試

同樣地，在所有sysbench client同時執行命令模擬只寫負載，每次持續20分鐘，同時從console檢視資料庫CPU，IO，網路等metrics。在這裡我們將通過修改num_threads引數連續測試4*32,4*64,4*128和4*256多種併發連線的場景。

sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=32 --percentile=95  --report-interval=20 oltp_write_only run >> <dbname>_write.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=64 --percentile=95  --report-interval=20 oltp_write_only run >> <dbname>_write.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=128 --percentile=95  --report-interval=20 oltp_write_only run >> <dbname>_write.log
  sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=256 --percentile=95  --report-interval=20 oltp_write_only run >> <dbname>_write.log

清除測試資料

sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-port=<port> --mysql-user=<username> --mysql-password=<password> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --time=600  oltp_write_only cleanup

讀/寫混合壓力測試

測試資料注入

sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-port=<port> --mysql-user=<username> --mysql-password=<password> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --time=600  oltp_read_write  prepare

測試

同樣地，在所有sysbench client同時執行命令模擬讀寫混合負載，每次持續20分鐘，同時從console檢視資料庫CPU，IO，網路等metrics。在這裡我們將通過修改num_threads引數連續測試4*32,4*64，4*128和4*200多種併發連線的場景。

sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=32 --percentile=95  --report-interval=20 oltp_read_write  run >> <dbname>_read_write.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=64 --percentile=95  --report-interval=20 oltp_read_write  run >> <dbname>_read_write.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=128--percentile=95  --report-interval=20 oltp_read_write  run >> <dbname>_read_write.log
sysbench --db-driver=mysql --mysql-host=<mysql host>  --mysql-user=<username> --mysql-password=<password> --mysql-port=<port>  --mysql-db=<dbname>   --table_size=25000 --tables=250 --events=0 --max-time=1200   --threads=200--percentile=95  --report-interval=20 oltp_read_write  run >> <dbname>_read_write.log

清除測試資料

sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-port=<port> --mysql-user=<username> --mysql-password=<password> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --time=600  oltp_read_write cleanup

結果分析

結果解讀

資料庫效能測試輸出結果中的指標包括：

• 每秒執行事務數TPS（Transactions Per Second） 資料庫每秒執行的事務數，以COMMIT成功次數為準。
  • SysBench標準OLTP讀寫混合場景中一個事務包含18個讀寫SQL。
  • SysBench標準OLTP只讀場景中一個事務包含14個讀SQL（10條主鍵查詢、4條範圍查詢）。
  • SysBench標準OLTP只寫場景中一個事務包含4個寫SQL（2條UPDATE、1條DETELE、1條INSERT）。
• 每秒執行請求數QPS（Queries Per Second） 資料庫每秒執行的SQL數。

結果統計

在不同併發連線數下，使用預設引數組和優化引數組的MYSQL RDS只讀負載測試資料如下：

在不同併發連線數下，使用預設引數組和優化引數組的MYSQL RDS只寫負載測試資料如下：

在不同併發連線數下，使用預設引數組和優化引數組的MYSQL RDS讀/寫混合負載測試資料如下：

結論

通過以上測試資料，我們可以發現：

• 因為我們調整的引數主要針對寫入效能，故而對讀取效能影響較小，而對寫入效能影響較大 ，這從測試結果中得到了體現。
• 併發連線越多，優化相關引數對MYSQL RDS寫入和讀寫混合場景下的效能提升越明顯，最多時，只寫場景下同等負載，優化引數組後RDS的平均響應時間可以縮小到預設引數組RDS平均響應時間的約1/5，TPS可以提升到預設引數組TPS的約5倍。
• 同理，對於讀寫混合場景，當併發數較大或者說寫入負載達到一定量時，引數調整的效果才可以展現出來，這是因為同樣的併發數讀寫混合場景的寫入負載小於只寫場景。
• 測試資料庫開啟了Multi-AZ以保證安全性,這會對效能產生較大影響,在分析資料時也必須考慮。