對單表億級數據的簡單測試

第一種：

單次查詢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