引子
你瞭解你們線上數據庫的真實處理速度嗎？請認真思考半分鐘再回答。
我先來回答一下：的確知道，因爲我特別關注這塊內容，諮詢過DBA同學。其他朋友歡迎在評論區留言，大家一起探討。
爲什麼會突然提出這樣一個問題呢，因爲前幾天看到一篇文章是講電商系統中如何優化庫存預佔能力，文中提到：“經壓測數據驗證，僅能支撐50次/秒，一旦發生熱點商品高頻預佔，TP99就會飆升，如果高頻預佔時間較長，會給系統帶來穩定性風險，鑑於這種情況必須對預佔做一系列優化之類的。”我不禁問自己，當年我們單臺數據庫好像也能輕鬆支持1000多的寫操作，這篇文章中提到的數據庫居然這麼脆弱，況且是來源於大廠的案例，硬件肯定不會太草率，一瞬間居然有點懷疑當年DBA給我的信息是否準確。
初步思考
冷靜下來思索一番，還是有點收穫的，我們當時的業務場景（聚合支付）其實很少有熱點數據的更新，比如之前提到的庫存預佔場景，我們大多數都是INSERT然後根據id做UPDATE，壓力被分散到多行，自然吞吐量高，可以拿JAVA中的ConcurrentHashMap和Hashtable來舉例，雖然都實現了線程安全，但是前者採用分段鎖機制而後者採用共享鎖，吞吐量一目瞭然。
“不同場景的性能指標沒有可比性，做系統設計的時候要先考慮場景，不能簡單的帶入過往的經驗”。
上手實驗
秉承着沒有調查就沒有發言權的原則，決定動手測試一番，準備工作很簡單：
1.本地搭建mysql，本次選用mysql8.0，調整innodb_buffer_pool_size的大小，直接給6G，innodb_buffer_pool_size感興趣的請參考終於做了一把MySQL調參boy；
2.使用mysql自帶的mysqlslap工具進行壓測，得到測試報告；
mysqlslap is a diagnostic program designed to emulate client load for a MySQL server and to report the timing of each stage. It works as if multiple clients are accessing the server.
(來自mysql官網介紹https://dev.mysql.com/doc/refman/8.0/en/mysqlslap.html）
3.測試場景模擬100個用戶對id=1的商品做10000次數量扣減，測試腳本如下：
mysqlslap --no-defaults -uroot -proot -P3306 --concurrency=100 --number-of-queries=10000 --create-schema=goods --query="UPDATE `goods`.`goods` SET `cnt` = `cnt`-1 WHERE (`ID` = 1);"--concurrency指定併發數爲100
--number-of-queries指定執行sql語句的次數爲10000
--create-schema要測試的目標數據庫
--query要執行的sql語句是針對id=1的商品做數量的扣減
4.解讀測試報告
執行完10000次查詢的的平均時間
Average number of seconds to run all queries: 47.797 seconds
執行完10000次查詢的的最小時間
Minimum number of seconds to run all queries: 47.797 seconds
執行完10000次查詢的的最大時間
Maximum number of seconds to run all queries: 47.797 seconds
100個客戶端執行本次測試
Number of clients running queries: 100
每個客戶端執行100次查詢
Average number of queries per client: 100大概估算下每秒能支撐10000/47.707=210次的熱點寫，比之前提到的50次/秒的確要高一些，但依然是一個數量級，況且我這個測試場景只是單一的模擬熱點商品的庫存扣減，和真實的業務場景還是有很大差距，綜合來講測試結果符合預期（一開始我也不相信，還發生了一點小插曲，後面會提到）。
這裏順便交代下我pc機的硬件情況：
1.cpu 13th Intel i5-13500H，核心數12，邏輯處理器16，頻率2.6 GHz；
2.內存32 GB（5200 MHz）
3.ssd硬盤
測試過程中cpu佔用率10%-15%、內存穩定在47%，磁盤寫入速度9 MB/秒，平均響應時間3-35毫秒。
小插曲
上一節提到測試出我本地mysql能支持210次/秒的熱點寫，比之前大廠文章中提到的50次/秒要高出3倍左右，一開始懷疑是mysql版本的問題，我假設大廠應該用的還是更穩定的5.7版本，所以本地又啓動了5.7版本的mysql用來測試，誰承想測試結果更讓人奔潰。
可以看到吞吐量達到了驚人的10000/2.297=4300次/秒的熱點寫，快的很假。
我開始對比本地mysql 5.7和8.0之間的參數差異，對比一番以後發現原來5.7版本的binlog默認是關閉的，相當於少了10000次磁盤寫，速度當然是非常nice的，到此整個測試之旅算真正結束。
不要做一個拿來主義者，去測試，實踐出真知。
