SQL 查詢效率
很多人不知道SQL語句在SQL SERVER中是如何執行的,他們擔心自己所寫的SQL語句會被SQL SERVER誤解。比如:
select * from table1 where name='zhangsan' and tID > 10000
和執行:
select * from table1 where tID > 10000 and name='zhangsan'
一
些人不知道以上兩條語句的執行效率是否一樣,因為如果簡單的從語句先後上看,這兩個語句的確是不一樣,如果tID是一個聚合索引,那麼後一句僅僅從表的
10000條以後的記錄中查詢就行了;而前一句則要先從全表中查詢看有幾個name='zhangsan'的,而後再根據限制條件條件tID>
10000來提出查詢結果。
事實上,這樣的擔心是不必要的。SQL SERVER中有一個“查詢分析優化器”,它可以計算出where子句中的搜尋條件並確定哪個索引能縮小表掃描的搜尋空間,也就是說,它能實現自動優化。
雖然查詢優化器可以根據where子句自動的進行查詢優化,但大家仍然有必要了解一下“查詢優化器”的工作原理,如非這樣,有時查詢優化器就會不按照您的本意進行快速查詢。
在查詢分析階段,查詢優化器檢視查詢的每個階段並決定限制需要掃描的資料量是否有用。如果一個階段可以被用作一個掃描引數(SARG),那麼就稱之為可優化的,並且可以利用索引快速獲得所需資料。
SARG的定義:用於限制搜尋的一個操作,因為它通常是指一個特定的匹配,一個值得範圍內的匹配或者兩個以上條件的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
這
條語句,從理論上講,整條語句的執行時間應該比子句的執行時間長,但事實相反。因為,子句執行後返回的是10000條記錄,而整條語句僅返回10條語句,
所以影響資料庫響應時間最大的因素是物理I/O操作。而限制物理I/O操作此處的最有效方法之一就是使用TOP關鍵詞了。TOP關鍵詞是SQL
SERVER中經過系統優化過的一個用來提取前幾條或前幾個百分比資料的詞。經筆者在實踐中的應用,發現TOP確實很好用,效率也很高。但這個詞在另外一
個大型資料庫ORACLE中卻沒有,這不能說不是一個遺憾,雖然在ORACLE中可以用其他方法(如:rownumber)來解決。在以後的關於“實現千
萬級資料的分頁顯示儲存過程”的討論中,我們就將用到TOP這個關鍵詞。
相關推薦
提高sql查詢效率
無法 結構 創建 存儲 開發 連續 新建 操作符 rom 1.對查詢進行優化,應盡量避免全表掃描,首先應考慮在 where 及 order by 涉及的列上建立索引。 2.應盡量避免在 where 子句中對字段進行 null 值判斷,否則將導致引擎放棄使用索引而進行全表掃描
轉:關於SQL查詢效率優化
1.關於SQL查詢效率,100w資料,查詢只要1秒,與您分享: 機器情況 p4: 2.4 記憶體: 1 G os: windows 2003 資料庫: ms sql server 2000 目的: 查詢效能測試,比較兩種查詢的效能 SQL查詢效率 step by step -- setp 1. --
資料庫SQL查詢效率in、exists、left join on、right join on 適用場景與比較
in 與 join例 select t1.id,sum(t1.num) from (select * from t2 where num =2) as t3 LEFT JOIN t1 on t3.id=t1.id GROUP BY t1.id; join 時間: 0.005
《提高SQL查詢效率的30種方法》
1.對查詢進行優化,應儘量避免全表掃描,首先應考慮在 where 及 order by 涉及的列上建立索引。 2.應儘量避免在 where 子句中對欄位進行 null 值判斷,否則將導致引擎放棄使用索引而進行全表掃描,如: select id from t
elasticsearch+logstash之間傳輸效率以及es-sql查詢效率簡單測試
對於logstash解析大批量資料並傳輸到elasticsearch中的過程簡單進行一些資料的測試,條件4G記憶體,logstash中配置index.refresh_interval=5s,(這個資料是es索引重新整理速率,就是資料傳輸到es中,es不會實時展示
Oracle提高SQL查詢效率where語句條件的先後次序
(1)選擇最有效率的表名順序(只在基於規則的優化器中有效): Oracle的解析器按照從右到左的順序處理FROM子句中的表名,FROM子句中寫在最後的表(基礎表 driving table)將被最先處理,在FROM子句中包含多個表的情況下,你必須選擇記錄條數最少的表作為基礎
SQL查詢效率提高方法
關於SQL查詢效率,100w資料,查詢只要1秒 1.關於SQL查詢效率,100w資料,查詢只要1秒,與您分享: 機器情況 p4: 2.4 記憶體: 1 G os: windows 2003 資料庫: ms sql server 2000 目的: 查
SQL 查詢效率
很多人不知道SQL語句在SQL SERVER中是如何執行的,他們擔心自己所寫的SQL語句會被SQL SERVER誤解。比如: select * from table1 where name='zhangsan' and tID > 10000 和執行: se
要提高SQL查詢效率where語句條件的先後次序應如何寫
我們要做到不但會寫SQL,還要做到寫出效能優良的SQL語句。 (1)選擇最有效率的表名順序(只在基於規則的優化器中有效): Oracle的解析器按照從右到左的順序處理FROM子句中的表名,FROM子句中寫在最後的表(基礎表 driving table)將被最先處理,在FROM子句中包含多個表的情況下,你必須
mybatis sql查詢條件有時間時查詢效率非常慢
最近在進行開發時發現一個奇葩的問題,sql在資料庫查詢速度不過1秒都不到在在後臺卻發現非常慢,通過列印dao方法時間和看mybatis log發現速度確實是很慢不是其他問題,然後一步步測試,首先加上<![CDATA[]]> 加在整個sql都沒用,然後加上<if></&g
MySQL - 如何提高SQL的查詢效率(where條件優化)
目錄 說在前面 35條優化規則 總結 說在前面 整天說SQL優化,SQL優化,到底怎麼才算是SQL優化呢,下面從百度總結了一些關於Oracle裡常用的一些有效的優化方法。僅供參考,文章內容來源於網路。 35條優化規則 (1)優先考慮建立索引 對查詢進行優化,應
Oracle - 如何提高SQL的查詢效率(where條件優化)
目錄 說在前面 34條優化規則 總結 說在前面 整天說SQL優化,SQL優化,到底怎麼才算是SQL優化呢,下面從百度總結了一些關於Oracle裡常用的一些有效的優化方法。僅供參考,文章內容來源於網路。 34條優化規則 (1)選擇最有效率的表名順序(只在基於規則的優
提高SQL Server資料庫查詢效率
1.應儘量避免在 where 子句中使用!=或<>操作符,否則將引擎放棄使用索引而進行全表掃描。 2.對查詢進行優化,應儘量避免全表掃描,首先應考慮在 where 及 order by 涉及的列上建立索引。 3.應儘量避免在 where 子句中對欄位
sql 提升查詢效率 group by option hash group
問題: 一個程式查詢經常超過20siis限制時間,排查問題後發現其中的一個儲存過程時間會在15s左右 解決思路: 1:確認問題點 通過輸出時間的方式檢視儲存過程中每個部分的執行時間,找到最耗時的三個過程 2:解決問題 發現查詢過程中出現 with nolock ,對於查詢過程沒有用處,刪除 先思
SQL Server: 建立 XML 索引 提升查詢效率
Scenario: 最近在工作中遇到一個問題,客戶訪問公司產品的某報表功能時,速度極慢,在客戶環境甚至達到15+分鐘的頁面載入時間。經分析,問題的原因是多方面的,其中最主要的一項是產品資料庫(SQL Server)的一個核心欄位採用了XML型別儲存,先不討論其設計的優劣,但大
MySQL 使用explain分析sql語句的查詢效率
Explain命令在解決資料庫效能上是第一推薦使用命令,大部分的效能問題可以通過此命令來簡單的解決,Explain可以用來檢視SQL語句的執行效 果,可以幫助選擇更好的索引和優化查詢語句,寫出更好的優化語句。Explain語法:EXPLAIN tbl_name或:EXPLAI
記錄一個sql優化後大大提高查詢效率的情形
眾所周知,sql寫得怎麼樣,對於查詢效率的影響是頗大的。下面看一個比較普通的查詢: 假設一張表有event_date和event_time2個欄位分別表示日期和時間,現在直接給你一個時間字串,這個時間字串是“日期+時間”的組合,現在需要按時間範圍過濾出一部分資料。如果你不轉彎的話,很有可能你會按照慣性思維使
在一個千萬級的資料庫查尋中,如何提高查詢效率?分別說出在資料庫設計、SQL語句、java等層面的解決方案
1)資料庫設計方面: a. 對查詢進行優化,應儘量避免全表掃描,首先應考慮在 where 及 order by 涉及的列上建立索引。 b. 應儘量避免在 where 子句中對欄位進行 null 值判斷,否則將導致引擎放棄使用索引而進行全表掃描,如: select id f
oracle sql強制走索引提高查詢效率
一般建表的時候加了縮影,使用這張表的對應欄位的時候,會走縮影,但是有時候會出現飄索引的現象;建議加上強制走索引的條件: select /*INDEX(bmq OPERATOR_CARD_MATCHE
MySQL 使用explain分析sql語句的查詢效率(一)
MySQL explain用於分析sql 語句的執行及資料庫索引的使用。本文將致力於幫助大家充分理解explain所返回的各項引數,從而使大家快速掌握explain用法技巧。如果你在看其他教程或視訊後仍覺得雲裡霧裡。那麼請通讀本文。 用法 explain的用法相當簡潔