詢問sql語句優化測試方法以下2句怎么測試出哪句性能更好?sel 愛問
這兩個SQL語句看起來都未能使用上索引,都是tablescan表掃操作,但是第一個SQL語句用了兩個LIKE,一個NULL的判斷。
一般情況下,IS NOT NULL比IS NULL的判斷更耗費資源。第二個SQL語句用了+運算和一個LIKE,好象比第一個性能要好一些。
但是當我在ASA中,隨意造了一個將近60萬條數據的堆表后,分別在PB中執行Explain SQL,分別顯示上面兩個SQL語句的執行計劃如下(表名我用的是test,字段分別是aa,bb): 1:( Plan [ Total Cost Estimate: 32。 96008 ] ( TableScan test[ ( ( test。
aa >= '' : 100% Statistics ) AND ( test。aa LIKE '%轉讓%' : 100% Computed ) ) OR ( ( >= '' : 100% Statistics ) AND ( LIKE '%轉讓%' : 100% Computed ) ) : 100% Combined ] ) ) 2:( Plan [ Total Cost Estimate: 32。
96008 ] ( TableScan test[ ( expr( test。aa, ) >= '' : 25% Guess ) AND ( expr( test。
aa, ) LIKE '%轉讓%' : 100% Computed ) ] ) ) 結果是兩個SQL語句的Total Cost Estimate都是一樣,所以直接從表面上看,很難判斷究竟哪個SQL性能更優,建議最好能夠在實際執行環境中測試一下。 當然WHERE條件越簡單,并且能夠優化使用上索引是最好的! 。
用sql數據庫怎么做軟件測試
前者通常來說,就是驗證前臺操作與數據庫的一致性,比如你在前臺刪除、增加、修改一條數據,數據庫相應的表內是否有相應的記錄變化,這是最基本的
如果你說是做數據庫測試,牽涉到很多,不過,對于我們測試人員做的哦比較多的數據庫的并發,打個比方說吧,我們對一個有5個字段的表test進行基本測試,驗證兩種情況:一,某字段order_no有索引;二,字段order_no無所有,有無索引時做相同的測試驗證
測試驗證分同時并發和分鐘并發兩種情況驗證 ,并發數從10、20、100、1000不等表中有50000條數據,通過比較響應時間得出測試結論。
做數據庫測試不多,也覺得三兩句說不清除!
如何測試sql語句性能,提高執行效率
有時候我們經常為我們的sql語句執行效率低下發愁,反復優化后,可還是得不到提高
那么你就用這條語句找出你sql到底是在哪里慢了
示例:
SET STATISTICS io ON
SET STATISTICS time
ON
go
---你要測試的sql語句
select top 100 * from
TBL_Cot_RecStaticList
go
SET STATISTICS profile
OFF
SET STATISTICS io OFF
SET STATISTICS time OFF
顯示信息:
SQL Server 分析和編譯時間:
CPU 時間 = 0 毫秒,占用時間 = 59 毫秒。
(100 行受影響) 表 'TBL_Cot_RecStaticList'。掃描計數 1,邏輯讀取 14 次,物理讀取 2
次,預讀 992 次,lob 邏輯讀取 0 次,lob 物理讀取 0 次,lob 預讀 0 次。
SQL Server 執行時間: CPU 時間 = 0 毫秒,占用時間 = 306 毫秒。
SQL Server 分析和編譯時間: CPU 時間 = 0 毫秒,占用時間 = 1 毫秒。
SQL Server 執行時間: CPU 時間 = 0 毫秒,占用時間 = 1 毫秒。
SQL Server 執行時間: CPU 時間 = 0 毫秒,占用時間 = 1 毫秒。
PL/SQl怎么測試一個sql語句的性能
一段SQL代碼寫好以后,可以通過查看SQL的執行計劃,初步預測該SQL在運行時的性能好壞,尤其是在發現某個SQL語句的效率較差時,我們可以通過查看執行計劃,分析出該SQL代碼的問題所在。
1、 打開熟悉的查看工具:PL/SQL Developer。
在PL/SQL Developer中寫好一段SQL代碼后,按F5,PL/SQL Developer會自動打開執行計劃窗口,顯示該SQL的執行計劃。
2、 查看總COST,獲得資源耗費的總體印象
一般而言,執行計劃第一行所對應的COST(即成本耗費)值,反應了運行這段SQL的總體估計成本,單看這個總成本沒有實際意義,但可以拿它與相同邏輯不同執行計劃的SQL的總體COST進行比較,通常COST低的執行計劃要好一些。
3、 按照從左至右,從上至下的方法,了解執行計劃的執行步驟
執行計劃按照層次逐步縮進,從左至右看,縮進最多的那一步,最先執行,如果縮進量相同,則按照從上而下的方法判斷執行順序,可粗略認為上面的步驟優先執行。每一個執行步驟都有對應的COST,可從單步COST的高低,以及單步的估計結果集(對應ROWS/基數),來分析表的訪問方式,連接順序以及連接方式是否合理。
4、 分析表的訪問方式
表的訪問方式主要是兩種:全表掃描(TABLE ACCESS FULL)和索引掃描(INDEX SCAN),如果表上存在選擇性很好的索引,卻走了全表掃描,而且是大表的全表掃描,就說明表的訪問方式可能存在問題;若大表上沒有合適的索引而走了全表掃描,就需要分析能否建立索引,或者是否能選擇更合適的表連接方式和連接順序以提高效率。
5、 分析表的連接方式和連接順序
表的連接順序:就是以哪張表作為驅動表來連接其他表的先后訪問順序。
表的連接方式:簡單來講,就是兩個表獲得滿足條件的數據時的連接過程。主要有三種表連接方式,嵌套循環(NESTED LOOPS)、哈希連接(HASH JOIN)和排序-合并連接(SORT MERGE JOIN)。我們常見得是嵌套循環和哈希連接。
嵌套循環:最適用也是最簡單的連接方式。類似于用兩層循環處理兩個游標,外層游標稱作驅動表,Oracle檢索驅動表的數據,一條一條的代入內層游標,查找滿足WHERE條件的所有數據,因此內層游標表中可用索引的選擇性越好,嵌套循環連接的性能就越高。
哈希連接:先將驅動表的數據按照條件字段以散列的方式放入內存,然后在內存中匹配滿足條件的行。哈希連接需要有合適的內存,而且必須在CBO優化模式下,連接兩表的WHERE條件有等號的情況下才可以使用。哈希連接在表的數據量較大,表中沒有合適的索引可用時比嵌套循環的效率要高。