掌握數據庫的性能情況是非常必要的。本文介紹了MySQL基準測試的基本概念，以及使用sysbench對MySQL進行基準測試的詳細方法,本文主要針對金山的單版RDS數據庫測試。
一、基準測試簡介
1、什麼是基準測試
數據庫的基準測試是對數據庫的性能指標進行定量的、可復現的、可對比的測試。
基準測試與壓力測試
基準測試可以理解爲針對系統的一種壓力測試。但基準測試不關心業務邏輯，更加簡單、直接、易於測試，數據可以由工具生成，不要求真實；而壓力測試一般考慮業務邏輯(如購物車業務)，要求真實的數據。
2、基準測試的作用
對於多數Web應用，整個系統的瓶頸在於數據庫；原因很簡單：Web應用中的其他因素，例如網絡帶寬、負載均衡節點、應用服務器（包括CPU、內存、硬盤燈、連接數等）、緩存，都很容易通過水平的擴展（俗稱加機器）來實現性能的提高。而對於MySQL，由於數據一致性的要求，無法通過增加機器來分散向數據庫寫數據帶來的壓力；雖然可以通過前置緩存（Redis等）、讀寫分離、分庫分表來減輕壓力，但是與系統其它組件的水平擴展相比，受到了太多的限制。
而對數據庫的基準測試的作用，就是分析在當前的配置下（包括硬件配置、OS、數據庫設置等），數據庫的性能表現，從而找出MySQL的性能閾值，並根據實際系統的要求調整配置。
3、基準測試的指標
常見的數據庫指標包括：
TPS/QPS：衡量吞吐量。（TPS：每秒事務處理量(TransactionPerSecond)、每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準）
響應時間：包括平均響應時間、最小響應時間、最大響應時間、時間百分比等，其中時間百分比參考意義較大，如前95%的請求的最大響應時間。。
併發量：同時處理的查詢請求的數量。
1
2
3
4、基準測試的分類
對MySQL的基準測試，有如下兩種思路：
（1）針對整個系統的基準測試：通過http請求進行測試，如通過瀏覽器、APP或postman等測試工具。該方案的優點是能夠更好的針對整個系統，測試結果更加準確；缺點是設計複雜實現困難。
（2）只針對MySQL的基準測試：優點和缺點與針對整個系統的測試恰好相反。
在針對MySQL進行基準測試時，一般使用專門的工具進行，例如mysqlslap、sysbench等。其中，sysbench比mysqlslap更通用、更強大，且更適合Innodb（因爲模擬了許多Innodb的IO特性），下面介紹使用sysbench進行基準測試的方法。
二、部署環境
首先創建一臺雲主機
創建RDS實例並將雲主機添加到RDS實例
在雲主機終端上可以用命令行連接到RDS數據庫，如下：
[root@vm192-168-80-2 sysbench-1.0]# mysql -h 192.168.89.18 -u admin -p
1
三、sysbench
1、sysbench簡介
sysbench是跨平臺的基準測試工具，支持多線程，支持多種數據庫；主要包括以下幾種測試：
cpu性能
磁盤io性能
調度程序性能
內存分配及傳輸速度
POSIX線程性能
數據庫性能(OLTP基準測試)
1
2
3
4
5
6
本文主要介紹對數據庫性能的測試。
2、sysbench安裝
本文使用的環境時CentOS 6.8；在其他Linux系統上的安裝方法大同小異。MySQL版本是5.6。
下載解壓
wget https://github.com/akopytov/sysbench/archive/1.0.zip -O "sysbench-1.0.zip"
unzip sysbench-1.0.zip
cd sysbench-1.0
1
2
3
安裝依賴
yum install automake libtool –y
1
安裝
./autogen.sh
./configure
make
make install
1
2
3
4
安裝成功
sysbench --version
sysbench 1.0.9
1
2
3、sysbench語法
執行sysbench –help，可以看到sysbench的詳細使用方法。
sysbench的基本語法如下：
sysbench [options]… [testname] [command]
下面說明實際使用中，常用的參數和命令。
（1）command
command是sysbench要執行的命令，包括prepare、run和cleanup，顧名思義，prepare是爲測試提前準備數據，run是執行正式的測試，cleanup是在測試完成後對數據庫進行清理。
（2）testname
testname指定了要進行的測試，在老版本的sysbench中，可以通過–test參數指定測試的腳本；而在新版本中，–test參數已經聲明爲廢棄，可以不使用–test，而是直接指定腳本。
例如，如下兩種方法效果是一樣的：
sysbench --test=./tests/include/oltp_legacy/oltp.lua
sysbench ./tests/include/oltp_legacy/oltp.lua
1
2
測試時使用的腳本爲lua腳本，可以使用sysbench自帶腳本，也可以自己開發。對於大多數應用，使用sysbench自帶的腳本就足夠了。不同版本的sysbench中，lua腳本的位置可能不同，可以自己在sysbench路徑下使用find命令搜索oltp.lua。P.S.：大多數數據服務都是oltp類型的，如果你不瞭解什麼是oltp，那麼大概率你的數據服務就是oltp類型的。
（3）options
sysbench的參數有很多，其中比較常用的包括：
MySQL連接信息參數
--mysql-host：MySQL服務器主機名，默認localhost；如果在本機上使用localhost報錯，提示無法連接MySQL服務器，改成本機的IP地址應該就可以了。
--mysql-port：MySQL服務器端口，默認3306
--mysql-user：用戶名
--mysql-password：密碼
1
2
3
4
MySQL執行參數
--oltp-test-mode：執行模式，包括simple、nontrx和complex，默認是complex。simple模式下只測試簡單的查詢；nontrx不僅測試查詢，還測試插入更新等，但是不使用事務；complex模式下測試最全面，會測試增刪改查，而且會使用事務。可以根據自己的需要選擇測試模式。
--oltp-tables-count：測試的表數量，根據實際情況選擇
--oltp-table-size：測試的表的大小，根據實際情況選擇
--threads：客戶端的併發連接數
--time：測試執行的時間，單位是秒，該值不要太短，可以選擇120
--report-interval：生成報告的時間間隔，單位是秒，如10
1
2
3
4
5
6
4、sysbench使用舉例
在執行sysbench時，應該注意：
（1）儘量不要在MySQL服務器運行的機器上進行測試，一方面可能無法體現網絡（哪怕是局域網）的影響，另一方面，sysbench的運行（尤其是設置的併發數較高時）會影響MySQL服務器的表現。
（2）可以逐步增加客戶端的併發連接數（–thread參數），觀察在連接數不同情況下，MySQL服務器的表現；如分別設置爲10,20,50,100等。
（3）一般執行模式選擇complex即可，如果需要特別測試服務器只讀性能，或不使用事務時的性能，可以選擇simple模式或nontrx模式。
（4）如果連續進行多次測試，注意確保之前測試的數據已經被清理乾淨。
下面是sysbench使用的一個例子：
（1）準備數據
sysbench ./tests/include/oltp_legacy/oltp.lua --mysql-host=192.168.89.18 --mysql-port=3306 --mysql-user=admin --mysql-password=Aa123456 --oltp-test-mode=complex --oltp-tables-count=10 --oltp-table-size=100000 --threads=10 --time=120 --report-interval=10 prepare
1
使用了10個表，每個表有10萬條數據，客戶端的併發線程數爲10，執行時間爲120秒，每10秒生成一次報告。
（2）執行測試
將測試結果導出到文件中，便於後續分析。
sysbench ./tests/include/oltp_legacy/oltp.lua --mysql-host=192.168.89.18 --mysql-port=3306 --mysql-user=admin --mysql-password=Aa123456 --oltp-test-mode=complex --oltp-tables-count=10 --oltp-table-size=100000 --threads=10 --time=120 --report-interval=10 run >> /root/test/mysysbench.log
1
（3）清理數據
執行完測試後，清理數據，否則後面的測試會受到影響。
[root@vm192-168-80-2 sysbench-1.0]# sysbench ./tests/include/oltp_legacy/oltp.lua --mysql-host=192.168.89.18 --mysql-port=3306 --mysql-user=admin --mysql-password=Aa123456 cleanup
sysbench 1.0.14 (using bundled LuaJIT 2.1.0-beta2)
Dropping table 'sbtest1'...
1
2
3
4
5、測試結果
測試結束後，查看輸出文件，如下所示：
sysbench 1.0.14 (using bundled LuaJIT 2.1.0-beta2)
Running the test with following options:
Number of threads: 10
Report intermediate results every 10 second(s)
Initializing random number generator from current time
Initializing worker threads...
--線程啓動
Threads started!
-- 每10秒鐘報告一次測試結果，tps、每秒讀、每秒寫、99%以上的響應時長統計
[ 10s ] thds: 10 tps: 956.45 qps: 19139.38 (r/w/o: 13399.56/3825.92/1913.91) lat (ms,95%): 29.72 err/s: 0.00 reconn/s: 0.00
[ 20s ] thds: 10 tps: 989.71 qps: 19804.24 (r/w/o: 13862.17/3962.55/1979.52) lat (ms,95%): 28.67 err/s: 0.10 reconn/s: 0.00
[ 30s ] thds: 10 tps: 995.44 qps: 19909.03 (r/w/o: 13936.11/3982.05/1990.87) lat (ms,95%): 27.66 err/s: 0.00 reconn/s: 0.00
[ 40s ] thds: 10 tps: 983.30 qps: 19660.90 (r/w/o: 13764.23/3930.08/1966.59) lat (ms,95%): 27.66 err/s: 0.00 reconn/s: 0.00
[ 50s ] thds: 10 tps: 994.20 qps: 19882.58 (r/w/o: 13918.26/3975.92/1988.41) lat (ms,95%): 29.19 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 10 tps: 982.50 qps: 19648.18 (r/w/o: 13752.56/3930.82/1964.81) lat (ms,95%): 28.16 err/s: 0.00 reconn/s: 0.00
[ 70s ] thds: 10 tps: 981.10 qps: 19624.20 (r/w/o: 13737.80/3924.00/1962.40) lat (ms,95%): 29.19 err/s: 0.00 reconn/s: 0.00
[ 80s ] thds: 10 tps: 991.69 qps: 19837.87 (r/w/o: 13885.81/3968.67/1983.39) lat (ms,95%): 27.17 err/s: 0.00 reconn/s: 0.00
[ 90s ] thds: 10 tps: 1007.34 qps: 20142.36 (r/w/o: 14100.50/4027.27/2014.59) lat (ms,95%): 26.68 err/s: 0.00 reconn/s: 0.00
[ 100s ] thds: 10 tps: 1009.76 qps: 20195.17 (r/w/o: 14135.79/4039.75/2019.63) lat (ms,95%): 26.20 err/s: 0.00 reconn/s: 0.00
[ 110s ] thds: 10 tps: 1003.80 qps: 20077.42 (r/w/o: 14053.54/4016.28/2007.59) lat (ms,95%): 25.74 err/s: 0.00 reconn/s: 0.00
[ 120s ] thds: 10 tps: 984.30 qps: 19685.77 (r/w/o: 13781.75/3935.41/1968.61) lat (ms,95%): 28.67 err/s: 0.00 reconn/s: 0.00
SQL statistics:
queries performed:
read: 1663326 --讀總數
write: 475233 -- 寫總數
other: 237617 -- 其他操作總數(SELECT、INSERT、UPDATE、DELETE之外的操作，例如COMMIT等)
total: 2376176 -- 全部總數
transactions: 118808 (989.85 per sec.) -- 總事務數(每秒事務數)
queries: 2376176 (19797.13 per sec.)
ignored errors: 1 (0.01 per sec.) --總忽略錯誤總數(每秒忽略錯誤次數)
reconnects: 0 (0.00 per sec.) --重連總數(每秒重連次數)
General statistics: --常規統計
total time: 120.0244s --總耗時
total number of events: 118808 --共發生多少事務數
Latency (ms):
min: 6.08 --最小耗時
avg: 10.10 --平均耗時
max: 87.65 --最長耗時
95th percentile: 28.16 --超過95%平均耗時
sum: 1199522.76
Threads fairness: --併發統計
events (avg/stddev): 11880.8000/273.15 --總處理事件數/標準偏差
execution time (avg/stddev): 119.9523/0.00 --總執行時間/標準偏差
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
其中，對於我們比較重要的信息包括：
queries：查詢總數及qps
transactions：事務總數及tps
Latency-95th percentile：前95%的請求的最大響應時間，本例中是28.16毫秒。
查看mysql連接數
6、建議
下面是使用sysbench的一些建議。
1、在開始測試之前，應該首先明確：應採用針對整個系統的基準測試，還是針對MySQL的基準測試，還是二者都需要。
2、如果需要針對MySQL的基準測試，那麼還需要明確精度方面的要求：是否需要使用生產環境的真實數據，還是使用工具生成也可以；前者實施起來更加繁瑣。如果要使用真實數據，儘量使用全部數據，而不是部分數據。
3、基準測試要進行多次纔有意義。
4、測試時需要注意主從同步的狀態。
5、測試必須模擬多線程的情況，單線程情況不但無法模擬真實的效率，也無法模擬阻塞甚至死鎖情況