SQL 壓力測試實戰篇 - GetIt01

針對資料庫的測試，市面上已經有很多工具了，Google 上搜一下sql testing tool ， 他為你選出的工具，琳琅滿目，看花雙眼。

比如：40+ Best Database Testing Tools - ... 標籤：MySQLSQL資料庫 SQL壓力測試實戰篇 05-28 SQL壓力測試實戰篇 來自專欄有關SQL針對資料庫的測試，市面上已經有很多工具了，Google上搜一下sqltestingtool，他為你選出的工具，琳琅滿目，看花雙眼。

比如：40+BestDatabaseTestingTools-PopularDataTestingSolutions這篇文章列舉了總共43個測試工具，可以用來完成SQL的測試，包括生成測試數據，功能性測試，邏輯性測試，當然還有壓力測試。

在這裡羅列幾個工具，以便有應用場景的時候，可以拿起來直接用。

現在的應用系統，一般都會有好幾層，比如UI,AccessLayer,BusinessLayer,資料庫。

每一層都有自己獨立的測試工具，下面的工具可能會同時支持其中1,2層對應的測試。

TestDataGenerator: 1.datafactory商業用資料庫數據生成工廠。

主要特點有：1.生成數據2.壓力測試2.MockupData3.DTMDataGeneratorSQL-BasedTools:1.SQLServerDatabasetools2.SQLTest:usestSQLtframeworktomaketestonviews,storedproceduresandfunctions。

使用的是tSQLt測試框架，用來測試試圖，存儲過程以及函數3.tSQLt:dedicatedtosqlserver 4.oraclesqldeveloper:5.NoSQLUnit:6.NoSQLMap:7.SeLite:combinationofseleniumandSQLite,knownasSeleniumextension8.SQLMap:opensourcetoolforSQLite,MySQL,SQLServer,DB2,PostgreSQLDBbasedLevelTestingtools:1.HammerDB:opensourcetoolfordatabaseloadtesting,usedasbenchmarkingtoolforsqlserver,mysql,db2,oracle。

這款工具的優點在於，他是opensource即開源的工具，意味著你可以完全看到他的測試方案。

看不到測試方案的工具，其實對自己理解測試報告，是有障礙的，比如並發是怎麼協調的，測試用的邏輯腳本是不是能體現出測試要求。

UIEnhancedTools:自帶絢麗UI的一體化工具1.Toad。

這款工具就不用多說了，和Oracle打交道並且是大廠項目的話，Toad基本是必用工具。

2.DBVisualizer:toad旗下的可視化開發工具，最有用的一點是可以快速建立ER圖 3.Databasebenchmark:opensourcetoolforperformingstresstestingonadatabasethatcontainsalargevolumeofdata.Graphicvisualizationandreportingoptionsareadvancedfeaturesofthistool.開源工具，可視化配置測試用例，性能測試報告。

針對MySQL,Oracle,MariaDB:1.Navicat:formySQL,alsomanagedatainsqlserver,oracle,mysql,SQLite2.LoadRunnerforOracle:在BrentOzar的博客上找到一個非常棒的工具：SQLQueryStress,並且是opensource開源的。

可以從github上下載並使用。

https://www.brentozar.com/archive/2015/05/how-to-fake-load-tests-with-sqlquerystress說了那麼多，這才是本文的主角。

如果你是手機的Geek,我想你一定會喜歡Andriod.iPhone當然也有玩頭，只不過AppStore上線一應用，審批實在麻煩。

這款SQLQueryStress就像是Andriod上的應用一樣，隨你拆開來玩，一睹內部玄妙的機關。

Github是個重武器庫，當今的軟體替代品差不多都能找到。

大家看到的題圖，都是用了GitHub上的小爬蟲，從Instagram上扣下來的。

首先交代測試環境：1.測試工具：SQLQueryStress下載路徑：https://github.com/ErikEJ/SqlQueryStress2.測試用SQLServer伺服器：個人的vmware虛擬機，配置較低[email protected].測試方案： 3.1用戶響應時間：讀3.2伺服器CPU利用率今天暫時針對CPU做測試。

1.10個並發的情況下,平均響應時間在0.4973秒。

可以說妥妥的。

但細心的朋友肯定注意到，其實這裡只是單純的運行同一個SQL，想想是不是哪裡不夠嚴謹，哪裡可以提高，哪裡是瓶頸？2.200個並發下，平均響應時間已經超過1s,接近2s了當這200個並發，一直在運行著查詢的時候，即使是同一個查詢，響應時間也已經不可接受了。

我們在本次實驗中，應用的是同一段腳本，同一段腳本運行完了之後，執行計劃會被緩存起來，相應的數據，也會在資料庫的緩存中保留下來，這樣的環境下，連續的發出查詢請求，其實對伺服器的CPU考核已經不是很嚴格了，不需要硬解析，不需要從資料庫磁碟拿出數據，但並發的響應時間依然不合格。

假如我們用一個總調度，根據線程ID來隨機抽取一個只讀存儲過程進行查詢，這樣的查詢對CPU的考驗才叫嚴格與真實。

剛才我們用10個並發的時候，系統沒有明顯的壓力，響應時間夠快。

這次我們就做10個存儲過程，當10個並發同時調用這10個存儲過程的時候，檢查響應時間，是不是依然合格！1利用AdventureWorks資料庫，編寫10個簡單的存儲過程2編寫一個總調度存儲過程，根據各自的線程ID，即session_id，來隨機調取其中一個存儲過程10個簡單的存儲過程可以這麼快速生成：DECLARE@sql_bodyNVARCHAR(max);DECLAREmy_curCURSORFORSELECTTOP10createprocedure+schema_name(schema_id)+.get+NAME+asbegin+selectcount(*)ascntfrom+schema_name(schema_id)+.+NAME+end+CHAR(10)+go FROMsys.objectsWHEREtype_desc=user_tableOPENmy_curFETCHNEXTFROMmy_curINTO@sql_bodyPRINT@sql_bodyWHILE@@fetch_status=0BEGINFETCHNEXT FROMmy_curINTO@sql_bodyPRINT@sql_body;ENDCLOSEmy_curDEALLOCATEmy_curGO總調度存儲過程：CREATEPROCEDUREdbo.usp_randRunQuery@threadsINT=10AS BEGINDECLARE@sql_bodyNVARCHAR(max);CREATETABLE#temp_procs(procedurenameNVARCHAR(max),idINTidentity(1,1))INSERTINTO#temp_procsSELECTTOP10exec+schema_name(schema_id)+.+NAMEFROMsys.objectsWHEREtype_desc=SQL_STORED_PROCEDUREORDERBYcreate_dateDESCSELECT@sql_body=procedurenameFROM#temp_procsWHEREid=@@spid%@threadsEXECsp_executesql@stmt=@sql_body;DROPTABLE#temp_procsEND當10個線程，調用不同的存儲過程時，響應速度依舊可以。

有峰值，但不過百在執行過程中，我發現並不是每一次的iteration都是固定的線程，有可能每一次執行，分配的處理線程會改變，因此需要多循環幾次，來保證每一個存儲過程都被調用，並且一段時間內有足夠多的並發在運行我的猜想是，到了一定的時間之後，相應時間會趨穩。

所以做了一個記錄每一個查詢的執行時間的功能，如下：1加一張Log表：createtableexecution_log(execidbigintidentity(1,1),spidint,procnamenvarchar(2000),start_dtdatetime,end_dtdatetime)2.修改我們的調度過程CREATEPROCEDUREdbo.usp_randRunQuery@threadsINT=10ASBEGINBEGINDECLARE@execidBIGINTDECLARE@sql_bodyNVARCHAR(2000);CREATETABLE#temp_procs(procedurenameNVARCHAR(2000),idINTidentity(1,1))INSERTINTO#temp_procsSELECTTOP10exec+schema_name(schema_id)+.+NAMEFROMsys.objectsWHEREtype_desc=SQL_STORED_PROCEDUREORDERBYcreate_dateDESCSETIDENTITY_INSERT#temp_procsOFFINSERTINTO#temp_procs(id,procedurename)SELECT0,procedurenameFROM#temp_procsWHEREid=6SETIDENTITY_INSERT#temp_procsONSELECT@sql_body=procedurenameFROM#temp_procsWHEREid=@@spid%@threads%10INSERTINTOexecution_log(spid,procname,start_dt)VALUES(@@spid,@sql_body,getutcdate())SELECT@execid=SCOPE_IDENTITY()EXECsp_executesql@stmt=@sql_body;UPDATEexecution_logSETend_dt=getutcdate()WHEREexecid=@execid;DROPTABLE#temp_procsENDEND果不出所料，再多的請求，相應時間也穩定下來了推薦閱讀： ※MySQL資料庫應用總結（八）—MySQL資料庫索引的操作※如何修改mysql密碼？※國內做分散式資料庫開發的現狀如何，有怎樣的發展前景？※注意！Riddle漏洞正在影響低版本OracleMySQL，請立即更新！※MySql的資料庫操作 TAG:SQL|MySQL|資料庫| 一點新知 GetIt01