SARG

SARG

計算機分析工具。

形式

如下:
列名 操作符 <;常數 或 變數>

<;常數 或 變數> 操作符列名列名可以出現在操作符的一邊,而常數或變數出現在操作符的另一邊。如:
Name=’張三’
價格>5000
5000<;價格
Name=’張三’ and 價格>5000 如果一個表達式不能滿足SARG的形式,那它就無法限制搜尋的範圍了,也就是SQL SERVER必須對每一行都判斷它是否滿足WHERE子句中的所有條件。所以一個索引對於不滿足SARG形式的表達式來說是無用的。
如果一個階段可以被用作一個掃描參數(SARG),那么就稱之為可最佳化的,並且可以利用索引快速獲得所需數據。

問題

通配符

Like語句是否屬於SARG取決於所使用的通配符的類型
如:name like ‘張%’ ,這就屬於SARG
而:name like ‘%張’,就不屬於SARG。
原因是通配符%在字元串的開通使得索引無法使用。

全表掃描

如:Name=’張三’ and 價格>5000 符號SARG,
而:Name=’張三’ or 價格>5000 則不符合SARG。
使用or會引起全表掃描

非操作符

不滿足SARG形式的語句最典型的情況就是包括非操作符的語句,如:NOT、!=、<>;、!<;、!>;、NOT EⅪSTS、NOT IN、NOT LIKE等,另外還有函式。下面就是幾個不滿足SARG形式的例子:
ABS(價格)<5000
Name like ‘%三’
有些表達式,如:
WHERE 價格*2>5000
SQL SERVER也會認為是SARG,SQL SERVER會將此式轉化為:
WHERE 價格>2500/2
但我們不推薦這樣使用,因為有時SQL SERVER不能保證這種轉化與原始表達式是完全等價的。

IN 相當與OR

語句:
Select * from table1 where tid in (2,3)

Select * from table1 where tid=2 or tid=3
是一樣的,都會引起全表掃描,如果tid上有索引,其索引也會失效。
儘量少用NOT

exists 和 in 的執行效率

很多資料上都顯示說,exists要比in的執行效率要高,同時應儘可能的用not exists來代替not in。但事實上,我試驗了一下,發現二者無論是前面帶不帶not,二者之間的執行效率都是一樣的。因為涉及子查詢,我們試驗這次用SQL SERVER自帶的pubs資料庫。運行前我們可以把SQL SERVER的statistics I/O狀態打開。
⑴select title,price from titles where title_id in
(select title_id from sales where qty>30)
該句的執行結果為:
表 'sales'。掃描計數 18,邏輯讀 56 次,物理讀 0 次,預讀 0 次。
表 'titles'。掃描計數 1,邏輯讀 2 次,物理讀 0 次,預讀 0 次。
⑵select title,price from titles where exists
(select * from sales where sales.title_id=titles.title_id and qty>30)
第二句的執行結果為:
表 'sales'。掃描計數 18,邏輯讀 56 次,物理讀 0 次,預讀 0 次。
表 'titles'。掃描計數 1,邏輯讀 2 次,物理讀 0 次,預讀 0 次。
我們從此可以看到用exists和用in的執行效率是一樣的。

用函式和通配符效率

前面,我們談到,如果在LIKE前面加上通配符%,那么將會引起全表掃描,所以其執行效率是低下的。但有的資料介紹說,用函式CHARINDEX()來代替LIKE速度會有大的提升,經我試驗,發現這種說明也是錯誤的:
select gid,title,fariqi,reader from tgongwen
where charindex('刑偵支隊',reader)>0 and fariqi>'2004-5-5'

函式

數據

用時:7秒,另外:掃描計數 4,邏輯讀 7155 次,物理讀 0 次,預讀 0 次。
select gid,title,fariqi,reader from tgongwen
where reader like '%' + '刑偵支隊' + '%' and fariqi>'2004-5-5'
用時:7秒,另外:掃描計數 4,邏輯讀 7155 次,物理讀 0 次,預讀 0 次。

union比or

我們前面已經談到了在where子句中使用or會引起全表掃描,一般的,我所見過的資料都是推薦這裡用union來代替or。事實證明,這種說法對於大部分都是適用的。
select gid,fariqi,neibuyonghu,reader,title from Tgongwen
where fariqi="2004-9-16" or gid>9990000
用時:68秒。掃描計數 1,邏輯讀 404008 次,物理讀 283 次,預讀 392163 次。
select gid,fariqi,neibuyonghu,reader,title from Tgongwen
where fariqi="2004-9-16"
union
select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid>9990000
用時:9秒。掃描計數 8,邏輯讀 67489 次,物理讀 216 次,預讀 7499 次。
看來,用union在通常情況下比用or的效率要高的多。
但經過試驗,筆者發現如果or兩邊的查詢列是一樣的話,那么用union則反倒和用or的執行速度差很多,雖然這裡union掃描的是索引,而or掃描的是全表。
select gid,fariqi,neibuyonghu,reader,title from Tgongwen
where fariqi="2004-9-16" or fariqi="2004-2-5"
用時:6423毫秒。掃描計數 2,邏輯讀 14726 次,物理讀 1 次,預讀 7176 次。
select gid,fariqi,neibuyonghu,reader,title from Tgongwen
where fariqi="2004-9-16"
union
select gid,fariqi,neibuyonghu,reader,title from Tgongwen
where fariqi="2004-2-5"
用時:11640毫秒。掃描計數 8,邏輯讀 14806 次,物理讀 108 次,預讀 1144 次。

避免select

我們來做一個試驗:
select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc
用時:4673毫秒
select top 10000 gid,fariqi,title from tgongwen order by gid desc
用時:1376毫秒
select top 10000 gid,fariqi from tgongwen order by gid desc
用時:80毫秒
由此看來,我們每少提取一個欄位,數據的提取速度就會有相應的提升。提升的速度還要看您捨棄的欄位的大小來判斷。

count不比count慢

某些資料上說:用*會統計所有列,顯然要比一個世界的列名效率低。這種說法其實是沒有根據的。我們來看:
select count(*) from Tgongwen
用時:1500毫秒
select count(gid) from Tgongwen
用時:1483毫秒
select count(fariqi) from Tgongwen
用時:3140毫秒
select count(title) from Tgongwen
用時:52050毫秒
從以上可以看出,如果用count(*)和用count(主鍵)的速度是相當的,而count(*)卻比其他任何除主鍵以外的欄位匯總速度要 快,而且欄位越長,匯總的速度就越慢。我想,如果用count(*), SQL SERVER可能會自動查找最小欄位來匯總的。當然,如果您直接寫count(主鍵)將會來的更直接些。

排序效率最高

我們來看:(gid是主鍵,fariqi是聚合索引列)
select top 10000 gid,fariqi,reader,title from tgongwen
用時:196 毫秒。掃描計數 1,邏輯讀 289 次,物理讀 1 次,預讀 1527 次。
select top 10000 gid,fariqi,reader,title from tgongwen order by gid asc
用時:4720毫秒。掃描計數 1,邏輯讀 41956 次,物理讀 0 次,預讀 1287 次。
select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc
用時:4736毫秒。掃描計數 1,邏輯讀 55350 次,物理讀 10 次,預讀 775 次。
select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi asc
用時:173毫秒。掃描計數 1,邏輯讀 290 次,物理讀 0 次,預讀 0 次。
select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi desc
用時:156毫秒。掃描計數 1,邏輯讀 289 次,物理讀 0 次,預讀 0 次。
從以上我們可以看出,不排序的速度以及邏輯讀次數都是和“order by 聚集索引列” 的速度是相當的,但這些都比“order by 非聚集索引列”的查詢速度是快得多的。
同時,按照某個欄位進行排序的時候,無論是正序還是倒序,速度是基本相當的。

高效的TOP

事實上,在查詢和提取超大容量的數據集時,影響資料庫回響時間的最大因素不是數據查找,而是物理的I/0操作。如:
select top 10 * from (
select top 10000 gid,fariqi,title from tgongwen
where neibuyonghu="辦公室"order by gid desc) as a
order by gid asc

相關詞條

相關搜尋

熱門詞條

聯絡我們