SARG(Searchable Arguments)的定義:用於限制搜索的一個操作,因爲它通常是指一個特定的匹配,一個值得範圍內的匹配或者兩個以上條件的AND連接。形式如下:
列名 操作符 <常數 或 變量>
或
<常數 或 變量> 操作符列名列名可以出現在操作符的一邊,而常數或變量出現在操作符的另一邊。如:
Name=’張三’
價格>5000
5000<價格
Name=’張三’ and 價格>5000 如果一個表達式不能滿足SARG的形式,那它就無法限制搜索的範圍了,也就是SQL SERVER必須對每一行都判斷它是否滿足WHERE子句中的所有條件。所以一個索引對於不滿足SARG形式的表達式來說是無用的。
如果一個階段可以被用作一個掃描參數(SARG),那麼就稱之爲可優化的,並且可以利用索引快速獲得所需數據。
總結一下使用SARG以及在實踐中遇到的和某些資料上結論不同的經驗: 1、Like語句是否屬於SARG取決於所使用的通配符的類型
如:name like ‘張%’ ,這就屬於SARG
而:name like ‘%張’ ,就不屬於SARG。
原因是通配符%在字符串的開通使得索引無法使用。
2、or 會引起全表掃描
如:Name=’張三’ and 價格>5000 符號SARG,
而:Name=’張三’ or 價格>5000 則不符合SARG。
使用or會引起全表掃描。
3、非操作符、函數引起的不滿足SARG形式的語句
不滿足SARG形式的語句最典型的情況就是包括非操作符的語句,如:NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等,另外還有函數。下面就是幾個不滿足SARG形式的例子:
ABS(價格)<5000
Name like ‘%三’
有些表達式,如:
WHERE 價格*2>5000
SQL SERVER也會認爲是SARG,SQL SERVER會將此式轉化爲:
WHERE 價格>2500/2
但我們不推薦這樣使用,因爲有時SQL SERVER不能保證這種轉化與原始表達式是完全等價的。
4、IN 的作用相當與OR
語句:
Select * from table1 where tid in (2,3)
和
Select * from table1 where tid=2 or tid=3
是一樣的,都會引起全表掃描,如果tid上有索引,其索引也會失效。
5、儘量少用NOT
6、exists 和 in 的執行效率是一樣的
很多資料上都顯示說,exists要比in的執行效率要高,同時應儘可能的用not exists來代替not in。但事實上,我試驗了一下,發現二者無論是前面帶不帶not,二者之間的執行效率都是一樣的。因爲涉及子查詢,我們試驗這次用SQL SERVER自帶的pubs數據庫。運行前我們可以把SQL SERVER的statistics I/O狀態打開。
(1)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 次。
(2)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的執行效率是一樣的。
7、用函數charindex()和前面加通配符%的LIKE執行效率一樣
前面,我們談到,如果在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 次。
8、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 次。
9、字段提取要按照“需多少、提多少”的原則,避免“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毫秒
由此看來,我們每少提取一個字段,數據的提取速度就會有相應的提升。提升的速度還要看您捨棄的字段的大小來判斷。
10、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(主鍵)將會來的更直接些。
11、order by按聚集索引列排序效率最高
我們來看:(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 非聚集索引列”的查詢速度是快得多的。
同時,按照某個字段進行排序的時候,無論是正序還是倒序,速度是基本相當的。
12、高效的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