本次對mysql做了單表億級數據量的壓測。
表的關系簡單，只有兩個int字段，user_id和company_id，且都增加了索引。
通過python腳本，隨機向同一個表隨機插入100W、500W、1000W-1E數據，并且記錄了每次插入數據所耗時間。
先來看下寫入數據的情況吧：
python腳本空轉：
空轉100W：0.14s
空轉1000W：1.74s
單次插入1000W條數據：295.11s
1000W基礎上再插入1000W，輪詢，直到寫入1E數據，記錄每次插入所耗的時間。

可以看到，隨著數據量的不斷增大，每次插入1000W條數據的時間還是比較穩定，上下浮動不大。

我們最終關心的是單表乙級數據量下，查詢速度能有多快。

下面是用python客戶端腳本模擬對1E條數據進行隨機查詢，隨機用的是python的隨機函數；機器資源有限，開發機是公用的，

所以也沒太敢占用太大資源來做壓測，并發用的Python的線程模塊。

本次查詢測試采用三種方法：

1、單進程對數據庫執行隨機查詢1000次操作，執行100次，記錄每次時間

2、并發1000、2000線程對數據庫進行隨機查詢1000次操作，記錄每次時間

3、用mysql官方軟件mysqlslap 對數據庫進行操作

單次查詢1000次的結果，跑100次，發現時間浮動還是比較大，這可能跟插入的數據散列情況有關，

user_id相同的數據還是有不少，20-100之間，線上業務出現這種數據的情況不大，所以，這些數據不影響最終結果。

第二種：并發1000線程對數據庫進行隨機1000次查詢，

1000線程：最慢時間8s，處理能力 125/s ；

2000線程：最慢時間10s，處理能力 100/s；

第三種：mysqlslap進行測試

開啟2000個線程，執行SELECT * FROM user_company_test_5000 WHERE user_id=7432查詢

平均處理時間8.76s，每秒能處理229個查詢。

用官方的mysqlslap進行測試，跟python腳本的測試結果偏差較大，

猜測原因有兩個：

1：mysqlslap 直接采用socket對Mysql進行連接，所以它除了 mysql處理時間和網絡請求時間沒有其他影響結果的操作

2：mysqlslap只能指定sql，沒有辦法隨機查詢數據，而測試表里面的數據分散不均勻，這也是一個原因。

mysqlslap的數據只能視為最好情況，但第二個python腳本則更接近生產環境，1000次查詢數據也是隨機查詢，

所以第二種能作為生產環境的依據。

再來看看批量查詢，IN 語句最多50個值

好吧，我只開了200個線程，最慢時間93s，最快時間46s，簡直可以用慘不忍睹來講。如果是批量查詢，

那就拆成多條語句來查吧。如果用IN ，必然會影響服務。

跟dba溝通過，理論上每秒能夠支持5000次的查詢量是比較正常的，但我用mysqlslap對單表100W的數據量進行了

測試，2000個client 每秒處理能力也只有700左右，

從第二種數據上看，當單機client達到2000時，每秒還能處理100次左右的查詢，還是不錯的。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com