sqlnotlike效率

『壹』 請問sql PLUS中的in和like的用法

當like和in能互換的時候，like時需要用到or

如 欄位 like '1%' or 欄位 like '2%'

如果改用in 則是substr(欄位,1,1) in (1,2)

不過後一種效率相對低，可能有的索引會用不上

你們老闆什麼意思，我也沒弄懂

『貳』 SQL 如果 TOP 值 大於表的總數據會不會影響查詢速度

在一百萬的數據量下測試，發現兩種方法的效率相同。
declare @i int
set @i = 1
while @i <= 1000000
begin
insert into MytestTable values(@i,'test')
set @i = @i+1
end

select top 1000001 * from dbo.MytestTable

select * from MytestTable

在我的機器上，查詢都是用了7秒鍾

-----------------------------
你不加order by不就完了？
order by應該不會提高效率的，微軟的機制是這樣的，先把所需要的數據查詢出來，然後再對相應欄位進行排序。所以排序這個過程需要對相應欄位進行遍歷掃描，需要時間的。

--------------------------
select top 200 * from (select * from user where isdel=0 and istop = 1) as U
where level in (2,5,8) and username like '%哈哈%'
order by U.update desc

『叄』 sql like 搜索效率問題 sql如下，當最後5個like同時存在時效率奇低，刪減掉任意一個like速度飛快

1 可以嘗試用charIndex代替like 如：and CharIndex('1', jbpmbusiness.RECV_NUM) > 0

2 如果不行可以嘗試把幾個拼接起來如
jbpmbusiness.RECV_NUM + 『,』 + jbpmbusiness.LWZH +',' like '%1%,%1%,'
逗號可以用其他不可能包含的字元替代
3 可以考慮資料庫冗餘一個欄位，格式如2，這個肯定快

『肆』 sql server有哪些查詢優化方法

可以通過如下方法來優化查詢 1、把數據、日誌、索引放到不同的I/O設備上，增加讀取速度，以前可以將Tempdb應放在RAID0上，SQL2000不在支持。數據量（尺寸）越大，提高I/O越重要. 2、縱向、橫向分割表，減少表的尺寸(sp_spaceuse) 3、升級硬體 4、根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。注意填充因子要適當（最好是使用默認值0）。索引應該盡量小，使用位元組數小的列建索引好（參照索引的創建）,不要對有限的幾個值的欄位建單一索引如性別欄位 5、提高網速; 6、擴大伺服器的內存,Windows 2000和SQL server 2000能支持4-8G的內存。配置虛擬內存：虛擬內存大小應基於計算機上並發運行的服務進行配置。運行 Microsoft SQL Server? 2000 時，可考慮將虛擬內存大小設置為計算機中安裝的物理內存的 1.5 倍。如果另外安裝了全文檢索功能，並打算運行 Microsoft 搜索服務以便執行全文索引和查詢，可考慮：將虛擬內存大小配置為至少是計算機中安裝的物理內存的 3 倍。將 SQL Server max server memory 伺服器配置選項配置為物理內存的 1.5 倍（虛擬內存大小設置的一半）。 7、 增加伺服器CPU個數;但是必須明白並行處理串列處理更需要資源例如內存。使用並行還是串列程是MsSQL自動評估選擇的。單個任務分解成多個任務，就可 以在處理器上運行。例如耽擱查詢的排序、連接、掃描和GROUP BY字句同時執行，SQL SERVER根據系統的負載情況決定最優的並行等級，復雜的需要消耗大量的CPU的查詢最適合並行處理。但是更新操作UPDATE,INSERT， DELETE還不能並行處理。 8、如果是使用like進行查詢的話，簡單的使用index是不行的，但是全文索引，耗空間。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查詢時，查詢耗時和欄位值總長度成正比,所以不能用CHAR類型，而是VARCHAR。對於欄位的值很長的建全文索引。 9、DB Server 和APPLication Server 分離；OLTP和OLAP分離 10、 分布式分區視圖可用於實現資料庫伺服器聯合體。聯合體是一組分開管理的伺服器，但它們相互協作分擔系統的處理負荷。這種通過分區數據形成資料庫伺服器聯合 體的機制能夠擴大一組伺服器，以支持大型的多層 Web 站點的處理需要。有關更多信息，參見設計聯合資料庫伺服器。（參照SQL幫助文件'分區視圖'） a、在實現分區視圖之前，必須先水平分區表 b、在創建成員表後，在每個成員伺服器上定義一個分布式分區視圖，並且每個視圖具有相同的名稱。這樣，引用分布式分區視圖名的查詢可以在任何一個成員服務 器上運行。系統操作如同每個成員伺服器上都有一個原始表的復本一樣，但其實每個伺服器上只有一個成員表和一個分布式分區視圖。數據的位置對應用程序是透明 的。 11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數據和日誌 DBCC SHRINKDB,DBCC SHRINKFILE. 設置自動收縮日誌.對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能。 在T-sql的寫法上有很大的講究，下面列出常見的要點：首先，DBMS處理查詢計劃的過程是這樣的：
1、 查詢語句的詞法、語法檢查 2、 將語句提交給DBMS的查詢優化器 3、 優化器做代數優化和存取路徑的優化 4、 由預編譯模塊生成查詢規劃 5、 然後在合適的時間提交給系統處理執行 6、 最後將執行結果返回給用戶其次，看一下SQL SERVER的數據存放的結構：一個頁面的大小為8K(8060)位元組，8個頁面為一個盤區，按照B樹存放。 12、Commit和rollback的區別 Rollback:回滾所有的事物。 Commit:提交當前的事物. 沒有必要在動態SQL里寫事物，如果要寫請寫在外面如： begin tran exec(@s) commit trans 或者將動態SQL 寫成函數或者存儲過程。 13、在查詢Select語句中用Where字句限制返回的行數,避免表掃描,如果返回不必要的數據，浪費了伺服器的I/O資源，加重了網路的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表,後果嚴重。 14、SQL的注釋申明對執行沒有任何影響 15、盡可能不使用游標，它佔用大量的資源。如果需要row-by-row地執行，盡量採用非游標技術,如：在客戶端循環，用臨時表，Table變數，用子查詢，用Case語句等等。游標可以按照它所支持的提取選項進行分類： 只進 必須按照從第一行到最後一行的順序提取行。FETCH NEXT 是唯一允許的提取操作,也是默認方式。可滾動性 可以在游標中任何地方隨機提取任意行。游標的技術在SQL2000下變得功能很強大，他的目的是支持循環。
有四個並發選項 READ_ONLY：不允許通過游標定位更新(Update)，且在組成結果集的行中沒有鎖。 OPTIMISTIC WITH valueS: 樂觀並發控制是事務控制理論的一個標准部分。樂觀並發控制用於這樣的情形，即在打開游標及更新行的間隔中，只有很小的機會讓第二個用戶更新某一行。當某個 游標以此選項打開時，沒有鎖控制其中的行，這將有助於最大化其處理能力。如果用戶試圖修改某一行，則此行的當前值會與最後一次提取此行時獲取的值進行比 較。如果任何值發生改變，則伺服器就會知道其他人已更新了此行，並會返回一個錯誤。如果值是一樣的，伺服器就執行修改。 選擇這個並發選項OPTIMISTIC WITH ROW VERSIONING:此樂觀並發控制選項基於行版本控制。使用行版本控制，其中的表必須具有某種版本標識符，伺服器可用它來確定該行在讀入游標後是否有所更改。 在 SQL Server 中，這個性能由 timestamp 數據類型提供，它是一個二進制數字，表示資料庫中更改的相對順序。每個資料庫都有一個全局當前時間戳值：@@DBTS。每次以任何方式更改帶有 timestamp 列的行時，SQL Server 先在時間戳列中存儲當前的 @@DBTS 值，然後增加 @@DBTS 的值。如果某 個表具有 timestamp 列，則時間戳會被記到行級。伺服器就可以比較某行的當前時間戳值和上次提取時所存儲的時間戳值，從而確定該行是否已更新。伺服器不必比較所有列的值，只需比較 timestamp 列即可。如果應用程序對沒有 timestamp 列的表要求基於行版本控制的樂觀並發，則游標默認為基於數值的樂觀並發控制。 SCROLL LOCKS 這個選項實現悲觀並發控制。在悲觀並發控制中，在把資料庫的行讀入游標結果集時，應用程序將試圖鎖定資料庫行。在使用伺服器游標時，將行讀入游標時會在其 上放置一個更新鎖。如果在事務內打開游標，則該事務更新鎖將一直保持到事務被提交或回滾；當提取下一行時，將除去游標鎖。如果在事務外打開游標，則提取下 一行時，鎖就被丟棄。因此，每當用戶需要完全的悲觀並發控制時，游標都應在事務內打開。更新鎖將阻止任何其它任務獲取更新鎖或排它鎖，從而阻止其它任務更 新該行。 然而，更新鎖並不阻止共享鎖，所以它不會阻止其它任務讀取行，除非第二個任務也在要求帶更新鎖的讀取。滾動鎖根據在游標定義的 SELECT 語句中指定的鎖提示，這些游標並發選項可以生成滾動鎖。滾動鎖在提取時在每行上獲取，並保持到下次提取或者游標關閉，以先發生者為准。下次提取時，伺服器 為新提取中的行獲取滾動鎖，並釋放上次提取中行的滾動鎖。滾動鎖獨立於事務鎖，並可以保持到一個提交或回滾操作之後。如果提交時關閉游標的選項為關， 則 COMMIT 語句並不關閉任何打開的游標，而且滾動鎖被保留到提交之後，以維護對所提取數據的隔離。所獲取滾動鎖的類型取決於游標並發選項和游標 SELECT 語句中的鎖提示。 鎖提示 只讀 樂觀數值 樂觀行版本控制 鎖定無提示 未鎖定 未鎖定 未鎖定 更新 NOLOCK 未鎖定 未鎖定 未鎖定 未鎖定 HOLDLOCK 共享 共享 共享 更新 UPDLOCK 錯誤 更新 更新 更新 TABLOCKX 錯誤 未鎖定 未鎖定 更新其它 未鎖定 未鎖定 未鎖定 更新 *指定 NOLOCK 提示將使指定了該提示的表在游標內是只讀的。
16、用Profiler來跟蹤查詢，得到查詢所需的時間，找出SQL的問題所在;用索引優化器優化索引 17、注意UNion和UNion all 的區別。UNION all好 18、注意使用DISTINCT，在沒有必要時不要用，它同UNION一樣會使查詢變慢。重復的記錄在查詢里是沒有問題的 19、查詢時不要返回不需要的行、列 20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT來限制查詢消耗的資源。當評估查詢消耗的資源超出限制時，伺服器自動取消查詢,在查詢之前就扼殺掉。 SET LOCKTIME設置鎖的時間 21、用select top 100 / 10 Percent 來限制用戶返回的行數或者SET ROWCOUNT來限制操作的行 22、在SQL2000以前，一般不要用如下的字句: "IS NULL", " <> ", "!=", "!> ", "! <", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'"，因為他們不走索引全是表掃描。也不要在WHere字句中的列名加函數，如Convert，substring等,如果必須用函數的時候，創建計算列再創建索引來替代.還可以變通寫法：WHERE SUBSTRING(firstname,1,1) = 'm'改為WHERE firstname like 'm%'（索引掃描），一定要將函數和列名分開。並且索引不能建得太多和太大。NOT IN會多次掃描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 來替代，特別是左連接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，現在2000的優化器能夠處理了。相同的是IS NULL，「NOT", "NOT EXISTS", "NOT IN"能優化她，而」 <> 」等還是不能優化，用不到索引。 23、使用Query Analyzer，查看SQL語句的查詢計劃和評估分析是否是優化的SQL。一般的20%的代碼占據了80%的資源，我們優化的重點是這些慢的地方。 24、如果使用了IN或者OR等時發現查詢沒有走索引，使用顯示申明指定索引： SELECT * FROM PersonMember (INDEX = IX_Title) WHERE processid IN (『男』，『女』) 25、將需要查詢的結果預先計算好放在表中，查詢的時候再SELECT。這在SQL7.0以前是最重要的手段。例如醫院的住院費計算。 26、MIN() 和 MAX()能使用到合適的索引 27、資料庫有一個原則是代碼離數據越近越好，所以優先選擇Default,依次為Rules,Triggers, Constraint（約束如外健主健CheckUNIQUE……,數據類型的最大長度等等都是約束）,Procere.這樣不僅維護工作小，編寫程序質量高，並且執行的速度快。 28、如果要插入大的二進制值到Image列，使用存儲過程，千萬不要用內嵌INsert來插入(不知java是否)。因為這樣應用程序首先將二進制值轉換成字元串（尺寸是它的兩倍），伺服器受到字元後又將他轉換成二進制值.存儲過程就沒有這些動作: 方法：Create procere p_insert as insert into table(Fimage) values (@image), 在前台調用這個存儲過程傳入二進制參數，這樣處理速度明顯改善。 29、Between在某些時候比IN速度更快,Between能夠更快地根據索引找到范圍。用查詢優化器可見到差別。 select * from chineseresume where title in ('男','女') Select * from chineseresume where between '男' and '女' 是一樣的。由於in會在比較多次，所以有時會慢些。 30、在必要是對全局或者局部臨時表創建索引，有時能夠提高速度，但不是一定會這樣，因為索引也耗費大量的資源。他的創建同是實際表一樣。 31、不要建沒有作用的事物例如產生報表時，浪費資源。只有在必要使用事物時使用它。 32、 用OR的字句可以分解成多個查詢，並且通過UNION 連接多個查詢。他們的速度只同是否使用索引有關,如果查詢需要用到聯合索引，用UNION all執行的效率更高.多個OR的字句沒有用到索引，改寫成UNION的形式再試圖與索引匹配。一個關鍵的問題是否用到索引。 33、 盡量少用視圖，它的效率低。對視圖操作比直接對表操作慢,可以用stored procere來代替她。特別的是不要用視圖嵌套,嵌套視圖增加了尋找原始資料的難度。我們看視圖的本質：它是存放在伺服器上的被優化好了的已經產生 了查詢規劃的SQL。對單個表檢索數據時，不要使用指向多個表的視圖，直接從表檢索或者僅僅包含這個表的視圖上讀，否則增加了不必要的開銷,查詢受到干 擾.為了加快視圖的查詢，MsSQL增加了視圖索引的功能。 34、沒有必要時不要用DISTINCT和ORDER BY，這些動作可以改在客戶端執行。它們增加了額外的開銷。這同UNION 和UNION ALL一樣的道理。 SELECT top 20 ad.companyname,comid,position,ad.referenceid,worklocation, convert(varchar(10),ad.postDate,120) as postDate1,workyear,degreedescription FROM jobcn_query.dbo.COMPANYAD_query ad where referenceID in('JCNAD00329667','JCNAD132168','JCNAD00337748','JCNAD00338345','JCNAD00333138','JCNAD00303570', 'JCNAD00303569','JCNAD00303568','JCNAD00306698','JCNAD00231935','JCNAD00231933','JCNAD00254567', 'JCNAD00254585','JCNAD00254608','JCNAD00254607','JCNAD00258524','JCNAD00332133','JCNAD00268618', 'JCNAD00279196','JCNAD00268613') order by postdate desc 35、在IN後面值的列表中，將出現最頻繁的值放在最前面，出現得最少的放在最後面，減少判斷的次數 36、當用SELECT INTO時，它會鎖住系統表(sysobjects，sysindexes等等)，阻塞其他的連接的存取。創建臨時表時用顯示申明語句，而不是 select INTO. drop table t_lxh begin tran select * into t_lxh from chineseresume where name = 'XYZ' --commit 在另一個連接中SELECT * from sysobjects可以看到 SELECT INTO 會鎖住系統表，Create table 也會鎖系統表(不管是臨時表還是系統表)。所以千萬不要在事物內使用它！！！這樣的話如果是經常要用的臨時表請使用實表，或者臨時表變數。 37、一般在GROUP BY 個HAVING字句之前就能剔除多餘的行，所以盡量不要用它們來做剔除行的工作。他們的執行順序應該如下最優：select 的Where字句選擇所有合適的行，Group By用來分組個統計行，Having字句用來剔除多餘的分組。這樣Group By 個Having的開銷小，查詢快.對於大的數據行進行分組和Having十分消耗資源。如果Group BY的目的不包括計算，只是分組，那麼用Distinct更快 38、一次更新多條記錄比分多次更新每次一條快,就是說批處理好 39、少用臨時表，盡量用結果集和Table類性的變數來代替它,Table 類型的變數比臨時表好 40、在SQL2000下，計算欄位是可以索引的，需要滿足的條件如下： a、計算欄位的表達是確定的 b、不能用在TEXT,Ntext，Image數據類型 c、必須配製如下選項 ANSI_NULLS = ON, ANSI_PADDINGS = ON, ……. 41、 盡量將數據的處理工作放在伺服器上，減少網路的開銷，如使用存儲過程。存儲過程是編譯好、優化過、並且被組織到一個執行規劃里、且存儲在資料庫中的 SQL語句，是控制流語言的集合，速度當然快。反復執行的動態SQL,可以使用臨時存儲過程，該過程（臨時表）被放在Tempdb中。以前由於SQL SERVER對復雜的數學計算不支持，所以不得不將這個工作放在其他的層上而增加網路的開銷。SQL2000支持UDFs,現在支持復雜的數學計算，函數 的返回值不要太大，這樣的開銷很大。用戶自定義函數象游標一樣執行的消耗大量的資源，如果返回大的結果採用存儲過程 42、不要在一句話里再三的使用相同的函數，浪費資源,將結果放在變數里再調用更快

『伍』 SQL的模糊匹配區別---like,rlike,regexpx

原文鏈接： https://blog.csdn.net/ZZQHELLO2018/java/article/details/92794555

一、主要區別
1)like的內容不是正則，而是通配符。像mysql中的"like",但是建議使用高級函數"instr"效率更高。

(2)rlike的內容可以是正則，正則的寫法與java一樣。需要轉義，例如』\m』需要使用』\m』

（3）regexp == rlike 同義詞 not like not regexp

二、Like常用方法
1.like關鍵字
like有兩個模式：_和%

_：表示單個字元，用來查詢定長的數據

%：表示0個或多個任意字元

2.示例

三、Mysql中Regexp常見用法
模糊匹配，包含特定字元串

模糊匹配，以特定字元串開頭

模糊匹配，以特定字元串結尾

模糊匹配 或關系

模糊匹配，不包含單個字元

這個結果跑出來一看大吃一驚，竟然把所有記錄給跑出來，這是為什麼呢？
因為一旦加了這個方括弧"[]"，它就把裡面的內容拆成單個的字元再匹配，它會逐個字元去匹配判斷是不是等於「車」，或者是不是等於「友「，返回的結果是一組0、1的邏輯值。

如果想匹配不包含特定字元串，該怎麼實現呢？

模糊匹配，不包含特定字元串

『陸』 SQL中哪些情況會引起全表掃描

1、模糊查詢效率很低：

原因：like本身效率就比較低，應該盡量避免查詢條件使用like；對於like 『%...%』（全模糊）這樣的條件，是無法使用索引的，全表掃描自然效率很低；另外，由於匹配演算法的關系，模糊查詢的欄位長度越大，模糊查詢效率越低。

解決辦法：首先盡量避免模糊查詢，如果因為業務需要一定要使用模糊查詢，則至少保證不要使用全模糊查詢，對於右模糊查詢，即like 『…%』，是會使用索引的；左模糊like

『%...』無法直接使用索引，但可以利用reverse + function index 的形式，變化成 like 『…%』；全模糊是無法優化的，一定要的話考慮用搜索引擎。出於降低資料庫伺服器的負載考慮，盡可能地減少資料庫模糊查詢。

2、查詢條件中含有is null的select語句執行慢

原因：Oracle 9i中，查詢欄位is null時單索引失效，引起全表掃描。

解決方法：SQL語法中使用NULL會有很多麻煩，最好索引列都是NOT NULL的；對於is null，可以建立組合索引，nvl(欄位,0),對表和索引analyse後，is null查詢時可以重新啟用索引查找,但是效率還不是值得肯定；is not null 時永遠不會使用索引。一般數據量大的表不要用is null查詢。

3、查詢條件中使用了不等於操作符（<>、!=）的select語句執行慢

原因：SQL中，不等於操作符會限制索引，引起全表掃描，即使比較的欄位上有索引

解決方法：通過把不等於操作符改成or，可以使用索引，避免全表掃描。例如，把column<>』aaa』，改成column<』aaa』 or column>』aaa』，就可以使用索引了。4、or語句使用不當會引起全表掃描

原因：where子句中比較的兩個條件，一個有索引，一個沒索引，使用or則會引起全表掃描。例如：where A==1 or B==2，A上有索引，B上沒索引，則比較B=：2時會重新開始全表掃描。


5、組合索引，排序時應按照組合索引中各列的順序進行排序，即使索引中只有一個列是要排序的，否則排序性能會比較差。
例如：create index skip1 on emp5(job,empno，date);
select job，empno from emp5 where job=』manager』and empno=』10』 order by job,empno,date desc;
實際上只是查詢出符合job=』manager』and empno=』10』條件的記錄並按date降序排列，但是寫成order by date desc性能較差。


6、Update 語句，如果只更改1、2個欄位，不要Update全部欄位，否則頻繁調用會引起明顯的性能消耗，同時帶來大量日誌。


7、對於多張大數據量（這里幾百條就算大了）的表JOIN，要先分頁再JOIN，否則邏輯讀會很高，性能很差。


8、select count(*) from table；這樣不帶任何條件的count會引起全表掃描，並且沒有任何業務意義，是一定要杜絕的。

『柒』 mysql 大數據量查詢如何優化，沒辦法去掉<>和like

其實你這個需要程序和資料庫有一致的設計。可考慮分區。
通過電話前綴來分區，以下只是一個形式，不推薦用中文命名，
這樣，只要用戶不填寫電話，那麼前三字元就是xxx，自動會放入 ZFU區。

CREATE TABLE Customer
(
ID INT NOT NULL,
Mobile_PerNO CHAR(3) DEFAULT 'xxx',
Mobile VARCHAR(30)
)
PARTITION BY LIST(Mobile_PerNO)
PARTITION 聯通186 VALUES IN (133),
PARTITION 移動139 VALUES IN (139),
PARTITION 電信133 VALUES IN (133),
PARTITION ZFU VALUES IN (xxx)
);

其次你過於依賴資料庫而成形的程序，用點不客氣的話說，那就是耦合極高的設計。
你其實完全可以在注冊時，寫入驗證，一個手機號就能注冊一次。左右打掉空格，這樣手機上就能建立唯一索引。 使用LIKE 『133%』 至少性能上有一定的飛躍。

至於你的第二個SQL， 在時間和發送號碼上可以建立索引，然後條件上寫入時間。
也可以使用hash方式按照年季度分區。

理論上 性能提升百倍還是一點問題都沒有的。

分區資料 看官方文檔。

『捌』 如何提高此sql語句的查詢效率

1. SQL優化的原則是：將一次操作需要讀取的BLOCK數減到最低,即在最短的時間達到最大的數據吞吐量。
調整不良SQL通常可以從以下幾點切入：
? 檢查不良的SQL，考慮其寫法是否還有可優化內容
? 檢查子查詢 考慮SQL子查詢是否可以用簡單連接的方式進行重新書寫
? 檢查優化索引的使用
? 考慮資料庫的優化器

2. 避免出現SELECT * FROM table 語句，要明確查出的欄位。

3. 在一個SQL語句中，如果一個where條件過濾的資料庫記錄越多，定位越准確，則該where條件越應該前移。

4. 查詢時盡可能使用索引覆蓋。即對SELECT的欄位建立復合索引，這樣查詢時只進行索引掃描，不讀取數據塊。

5. 在判斷有無符合條件的記錄時建議不要用SELECT COUNT （*）和select top 1 語句。

6. 使用內層限定原則，在拼寫SQL語句時，將查詢條件分解、分類，並盡量在SQL語句的最里層進行限定，以減少數據的處理量。

7. 應絕對避免在order by子句中使用表達式。

8. 如果需要從關聯表讀數據，關聯的表一般不要超過7個。

9. 小心使用 IN 和 OR，需要注意In集合中的數據量。建議集合中的數據不超過200個。

10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，這樣可以有效的利用索引。

11. 在查詢時盡量減少對多餘數據的讀取包括多餘的列與多餘的行。

12. 對於復合索引要注意，例如在建立復合索引時列的順序是F1，F2，F3，則在where或order by子句中這些欄位出現的順序要與建立索引時的欄位順序一致，且必須包含第一列。只能是F1或F1，F2或F1，F2，F3。否則不會用到該索引。

13. 多表關聯查詢時，寫法必須遵循以下原則，這樣做有利於建立索引，提高查詢效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值條件（=）) and (table1的非等值條件) and (table2與table1的關聯條件) and (table2的等值條件) and (table2的非等值條件) and (table3與table2的關聯條件) and (table3的等值條件) and (table3的非等值條件)。
注:關於多表查詢時from 後面表的出現順序對效率的影響還有待研究。

14. 子查詢問題。對於能用連接方式或者視圖方式實現的功能，不要用子查詢。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。應該用如下語句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。

15. 在WHERE 子句中，避免對列的四則運算，特別是where 條件的左邊，嚴禁使用運算與函數對列進行處理。比如有些地方 substring 可以用like代替。

16. 如果在語句中有not in（in）操作，應考慮用not exists（exists）來重寫,最好的辦法是使用外連接實現。

17. 對一個業務過程的處理，應該使事物的開始與結束之間的時間間隔越短越好，原則上做到資料庫的讀操作在前面完成，資料庫寫操作在後面完成，避免交叉。

18. 請小心不要對過多的列使用列函數和order by,group by等，謹慎使用disti軟體開發t。

19. 用union all 代替 union，資料庫執行union操作，首先先分別執行union兩端的查詢，將其放在臨時表中，然後在對其進行排序，過濾重復的記錄。
當已知的業務邏輯決定query A和query B中不會有重復記錄時，應該用union all代替union，以提高查詢效率。

數據更新的效率
1. 在一個事物中，對同一個表的多個insert語句應該集中在一起執行。
2. 在一個業務過程中，盡量的使insert,update,delete語句在業務結束前執行，以減少死鎖的可能性。

資料庫物理規劃的效率

為了避免I/O的沖突，我們在設計資料庫物理規劃時應該遵循幾條基本的原則(以ORACLE舉例)：
?? table和index分離：table和index應該分別放在不同的tablespace中。

?? Rollback Segment的分離：Rollback Segment應該放在獨立的Tablespace中。

?? System Tablespace的分離：System Tablespace中不允許放置任何用戶的object。（mssql中primary filegroup中不允許放置任何用戶的object）

?? Temp Tablesace的分離：建立單獨的Temp Tablespace，並為每個user指定default Temp Tablespace

??避免碎片：但segment中出現大量的碎片時，會導致讀數據時需要訪問的block數量的增加。對經常發生DML操作的segemeng來說，碎片是不能完全避免的。所以，我們應該將經常做DML操作的表和很少發生變化的表分離在不同的Tablespace中。

當我們遵循了以上原則後，仍然發現有I/O沖突存在，我們可以用數據分離的方法來解決。
?? 連接Table的分離：在實際應用中經常做連接查詢的Table，可以將其分離在不同的Taclespace中，以減少I/O沖突。

?? 使用分區：對數據量很大的Table和Index使用分區，放在不同的Tablespace中。

在實際的物理存儲中，建議使用RAID。日誌文件應放在單獨的磁碟中。

『玖』 SQL如何快速處理海量數據

在以下的文章中，我將以「辦公自動化」系統為例，探討如何在有著1000萬條數據的MS SQL SERVER資料庫中實現快速的數據提取和數據分頁。以下代碼說明了我們實例中資料庫的「紅頭文件」一表的部分數據結構：

CREATE TABLE [dbo].[TGongwen] ( --TGongwen是紅頭文件表名

[Gid] [int] IDENTITY (1, 1) NOT NULL ,
--本表的id號，也是主鍵

[title] [varchar] (80) COLLATE Chinese_PRC_CI_AS NULL ,
--紅頭文件的標題

[fariqi] [datetime] NULL ,
--發布日期

[neibuYonghu] [varchar] (70) COLLATE Chinese_PRC_CI_AS NULL ,
--發布用戶

[reader] [varchar] (900) COLLATE Chinese_PRC_CI_AS NULL ,

--需要瀏覽的用戶。每個用戶中間用分隔符「,」分開

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

下面，我們來往資料庫中添加1000萬條數據：

declare @i int

set @i=1

while @i<=250000

begin

insert into Tgongwen(fariqi,neibuyonghu,reader,title) values('2004-2-5','通信科','通信科,辦公室,王局長,劉局長,張局長,admin,刑偵支隊,特勤支隊,交巡警支隊,經偵支隊,戶政科,治安支隊,外事科','這是最先的25萬條記錄')

set @i=@i+1

end

GO

declare @i int

set @i=1

while @i<=250000

begin

insert into Tgongwen(fariqi,neibuyonghu,reader,title) values('2004-9-16','辦公室','辦公室,通信科,王局長,劉局長,張局長,admin,刑偵支隊,特勤支隊,交巡警支隊,經偵支隊,戶政科,外事科','這是中間的25萬條記錄')

set @i=@i+1

end

GO

declare @h int

set @h=1

while @h<=100

begin

declare @i int

set @i=2002

while @i<=2003

begin

declare @j int

set @j=0

while @j<50

begin

declare @k int

set @k=0

while @k<50

begin

insert into Tgongwen(fariqi,neibuyonghu,reader,title) values(cast(@i as varchar(4))+'-8-15 3:'+cast(@j as varchar(2))+':'+cast(@j as varchar(2)),'通信科','辦公室,通信科,王局長,劉局長,張局長,admin,刑偵支隊,特勤支隊,交巡警支隊,經偵支隊,戶政科,外事科','這是最後的50萬條記錄')

set @k=@k+1

end

set @j=@j+1

end

set @i=@i+1

end

set @h=@h+1

end

GO

declare @i int

set @i=1

while @i<=9000000

begin

insert into Tgongwen(fariqi,neibuyonghu,reader,title) values('2004-5-5','通信科','通信科,辦公室,王局長,劉局長,張局長,admin,刑偵支隊,特勤支隊,交巡警支隊,經偵支隊,戶政科,治安支隊,外事科','這是最後添加的900萬條記錄')

set @i=@i+1000000

end

GO

通過以上語句，我們創建了25萬條由通信科於2004年2月5日發布的記錄，25萬條由辦公室於2004年9月6日發布的記錄，2002年和2003年各100個2500條相同日期、不同分秒的由通信科發布的記錄（共50萬條），還有由通信科於2004年5月5日發布的900萬條記錄，合計1000萬條。

一、因情制宜，建立「適當」的索引

建立「適當」的索引是實現查詢優化的首要前提。

索引（index）是除表之外另一重要的、用戶定義的存儲在物理介質上的數據結構。當根據索引碼的值搜索數據時，索引提供了對數據的快速訪問。事實上，沒有索引,資料庫也能根據SELECT語句成功地檢索到結果，但隨著表變得越來越大，使用「適當」的索引的效果就越來越明顯。注意，在這句話中，我們用了「適當」這個詞，這是因為，如果使用索引時不認真考慮其實現過程，索引既可以提高也會破壞資料庫的工作性能。

（一）深入淺出理解索引結構

實際上，您可以把索引理解為一種特殊的目錄。微軟的SQL SERVER提供了兩種索引：聚集索引（clustered index，也稱聚類索引、簇集索引）和非聚集索引（nonclustered index，也稱非聚類索引、非簇集索引）。下面，我們舉例來說明一下聚集索引和非聚集索引的區別：

其實，我們的漢語字典的正文本身就是一個聚集索引。比如，我們要查「安」字，就會很自然地翻開字典的前幾頁，因為「安」的拼音是「an」，而按照拼音排序漢字的字典是以英文字母「a」開頭並以「z」結尾的，那麼「安」字就自然地排在字典的前部。如果您翻完了所有以「a」開頭的部分仍然找不到這個字，那麼就說明您的字典中沒有這個字；同樣的，如果查「張」字，那您也會將您的字典翻到最後部分，因為「張」的拼音是「zhang」。也就是說，字典的正文部分本身就是一個目錄，您不需要再去查其他目錄來找到您需要找的內容。

我們把這種正文內容本身就是一種按照一定規則排列的目錄稱為「聚集索引」。

如果您認識某個字，您可以快速地從自動中查到這個字。但您也可能會遇到您不認識的字，不知道它的發音，這時候，您就不能按照剛才的方法找到您要查的字，而需要去根據「偏旁部首」查到您要找的字，然後根據這個字後的頁碼直接翻到某頁來找到您要找的字。但您結合「部首目錄」和「檢字表」而查到的字的排序並不是真正的正文的排序方法，比如您查「張」字，我們可以看到在查部首之後的檢字表中「張」的頁碼是672頁，檢字表中「張」的上面是「馳」字，但頁碼卻是63頁，「張」的下面是「弩」字，頁面是390頁。很顯然，這些字並不是真正的分別位於「張」字的上下方，現在您看到的連續的「馳、張、弩」三字實際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結果，然後再翻到您所需要的頁碼。

我們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱為「非聚集索引」。

通過以上例子，我們可以理解到什麼是「聚集索引」和「非聚集索引」。

進一步引申一下，我們可以很容易的理解：每個表只能有一個聚集索引，因為目錄只能按照一種方法進行排序。

（二）何時使用聚集索引或非聚集索引

下面的表總結了何時使用聚集索引或非聚集索引（很重要）。

動作描述

使用聚集索引

使用非聚集索引

列經常被分組排序

應

應

返回某范圍內的數據

應

不應

一個或極少不同值

不應

不應

小數目的不同值

應

不應

大數目的不同值

不應

應

頻繁更新的列

不應

應

外鍵列

應

應

主鍵列

應

應

頻繁修改索引列

不應

應

事實上，我們可以通過前面聚集索引和非聚集索引的定義的例子來理解上表。如：返回某范圍內的數據一項。比如您的某個表有一個時間列，恰好您把聚合索引建立在了該列，這時您查詢2004年1月1日至2004年10月1日之間的全部數據時，這個速度就將是很快的，因為您的這本字典正文是按日期進行排序的，聚類索引只需要找到要檢索的所有數據中的開頭和結尾數據即可；而不像非聚集索引，必須先查到目錄中查到每一項數據對應的頁碼，然後再根據頁碼查到具體內容。

（三）結合實際，談索引使用的誤區

理論的目的是應用。雖然我們剛才列出了何時應使用聚集索引或非聚集索引，但在實踐中以上規則卻很容易被忽視或不能根據實際情況進行綜合分析。下面我們將根據在實踐中遇到的實際問題來談一下索引使用的誤區，以便於大家掌握索引建立的方法。

1、主鍵就是聚集索引

這種想法筆者認為是極端錯誤的，是對聚集索引的一種浪費。雖然SQL SERVER默認是在主鍵上建立聚集索引的。

通常，我們會在每個表中都建立一個ID列，以區分每條數據，並且這個ID列是自動增大的，步長一般為1。我們的這個辦公自動化的實例中的列Gid就是如此。此時，如果我們將這個列設為主鍵，SQL SERVER會將此列默認為聚集索引。這樣做有好處，就是可以讓您的數據在資料庫中按照ID進行物理排序，但筆者認為這樣做意義不大。

顯而易見，聚集索引的優勢是很明顯的，而每個表中只能有一個聚集索引的規則，這使得聚集索引變得更加珍貴。

從我們前面談到的聚集索引的定義我們可以看出，使用聚集索引的最大好處就是能夠根據查詢要求，迅速縮小查詢范圍，避免全表掃描。在實際應用中，因為ID號是自動生成的，我們並不知道每條記錄的ID號，所以我們很難在實踐中用ID號來進行查詢。這就使讓ID號這個主鍵作為聚集索引成為一種資源浪費。其次，讓每個ID號都不同的欄位作為聚集索引也不符合「大數目的不同值情況下不應建立聚合索引」規則；當然，這種情況只是針對用戶經常修改記錄內容，特別是索引項的時候會負作用，但對於查詢速度並沒有影響。

在辦公自動化系統中，無論是系統首頁顯示的需要用戶簽收的文件、會議還是用戶進行文件查詢等任何情況下進行數據查詢都離不開欄位的是「日期」還有用戶本身的「用戶名」。

通常，辦公自動化的首頁會顯示每個用戶尚未簽收的文件或會議。雖然我們的where語句可以僅僅限制當前用戶尚未簽收的情況，但如果您的系統已建立了很長時間，並且數據量很大，那麼，每次每個用戶打開首頁的時候都進行一次全表掃描，這樣做意義是不大的，絕大多數的用戶1個月前的文件都已經瀏覽過了，這樣做只能徒增資料庫的開銷而已。事實上，我們完全可以讓用戶打開系統首頁時，資料庫僅僅查詢這個用戶近3個月來未閱覽的文件，通過「日期」這個欄位來限製表掃描，提高查詢速度。如果您的辦公自動化系統已經建立的2年，那麼您的首頁顯示速度理論上將是原來速度8倍，甚至更快。

在這里之所以提到「理論上」三字，是因為如果您的聚集索引還是盲目地建在ID這個主鍵上時，您的查詢速度是沒有這么高的，即使您在「日期」這個欄位上建立的索引（非聚合索引）。下面我們就來看一下在1000萬條數據量的情況下各種查詢的速度表現（3個月內的數據為25萬條）：

（1）僅在主鍵上建立聚集索引，並且不劃分時間段：

Select gid,fariqi,neibuyonghu,title from tgongwen

用時：128470毫秒（即：128秒）

（2）在主鍵上建立聚集索引，在fariq上建立非聚集索引：

select gid,fariqi,neibuyonghu,title from Tgongwen

where fariqi> dateadd(day,-90,getdate())

用時：53763毫秒（54秒）

（3）將聚合索引建立在日期列（fariqi）上：

select gid,fariqi,neibuyonghu,title from Tgongwen

where fariqi> dateadd(day,-90,getdate())

用時：2423毫秒（2秒）

雖然每條語句提取出來的都是25萬條數據，各種情況的差異卻是巨大的，特別是將聚集索引建立在日期列時的差異。事實上，如果您的資料庫真的有1000萬容量的話，把主鍵建立在ID列上，就像以上的第1、2種情況，在網頁上的表現就是超時，根本就無法顯示。這也是我摒棄ID列作為聚集索引的一個最重要的因素。

得出以上速度的方法是：在各個select語句前加：declare @d datetime

set @d=getdate()

並在select語句後加：

select [語句執行花費時間(毫秒)]=datediff(ms,@d,getdate())

2、只要建立索引就能顯著提高查詢速度

事實上，我們可以發現上面的例子中，第2、3條語句完全相同，且建立索引的欄位也相同；不同的僅是前者在fariqi欄位上建立的是非聚合索引，後者在此欄位上建立的是聚合索引，但查詢速度卻有著天壤之別。所以，並非是在任何欄位上簡單地建立索引就能提高查詢速度。

從建表的語句中，我們可以看到這個有著1000萬數據的表中fariqi欄位有5003個不同記錄。在此欄位上建立聚合索引是再合適不過了。在現實中，我們每天都會發幾個文件，這幾個文件的發文日期就相同，這完全符合建立聚集索引要求的：「既不能絕大多數都相同，又不能只有極少數相同」的規則。由此看來，我們建立「適當」的聚合索引對於我們提高查詢速度是非常重要的。

3、把所有需要提高查詢速度的欄位都加進聚集索引，以提高查詢速度

上面已經談到：在進行數據查詢時都離不開欄位的是「日期」還有用戶本身的「用戶名」。既然這兩個欄位都是如此的重要，我們可以把他們合並起來，建立一個復合索引（compound index）。

很多人認為只要把任何欄位加進聚集索引，就能提高查詢速度，也有人感到迷惑：如果把復合的聚集索引欄位分開查詢，那麼查詢速度會減慢嗎？帶著這個問題，我們來看一下以下的查詢速度（結果集都是25萬條數據）：（日期列fariqi首先排在復合聚集索引的起始列，用戶名neibuyonghu排在後列）

（1）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>'2004-5-5'

查詢速度：2513毫秒

（2）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>'2004-5-5' and neibuyonghu='辦公室'

查詢速度：2516毫秒

（3）select gid,fariqi,neibuyonghu,title from Tgongwen where neibuyonghu='辦公室'

查詢速度：60280毫秒

從以上試驗中，我們可以看到如果僅用聚集索引的起始列作為查詢條件和同時用到復合聚集索引的全部列的查詢速度是幾乎一樣的，甚至比用上全部的復合索引列還要略快（在查詢結果集數目一樣的情況下）；而如果僅用復合聚集索引的非起始列作為查詢條件的話，這個索引是不起任何作用的。當然，語句1、2的查詢速度一樣是因為查詢的條目數一樣，如果復合索引的所有列都用上，而且查詢結果少的話，這樣就會形成「索引覆蓋」，因而性能可以達到最優。同時，請記住：無論您是否經常使用聚合索引的其他列，但其前導列一定要是使用最頻繁的列。

（四）其他書上沒有的索引使用經驗總結

1、用聚合索引比用不是聚合索引的主鍵速度快

下面是實例語句：（都是提取25萬條數據）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16'

使用時間：3326毫秒

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid<=250000

使用時間：4470毫秒

這里，用聚合索引比用不是聚合索引的主鍵速度快了近1/4。

2、用聚合索引比用一般的主鍵作order by時速度快，特別是在小數據量情況下

select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by fariqi

用時：12936

select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by gid

用時：18843

這里，用聚合索引比用一般的主鍵作order by時，速度快了3/10。事實上，如果數據量很小的話，用聚集索引作為排序列要比使用非聚集索引速度快得明顯的多；而數據量如果很大的話，如10萬以上，則二者的速度差別不明顯。

3、使用聚合索引內的時間段，搜索時間會按數據占整個數據表的百分比成比例減少，而無論聚合索引使用了多少個

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-1-1'

用時：6343毫秒（提取100萬條）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-6-6'

用時：3170毫秒（提取50萬條）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16'

用時：3326毫秒（和上句的結果一模一樣。如果採集的數量一樣，那麼用大於號和等於號是一樣的）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-1-1' and fariqi<'2004-6-6'

用時：3280毫秒

4 、日期列不會因為有分秒的輸入而減慢查詢速度

下面的例子中，共有100萬條數據，2004年1月1日以後的數據有50萬條，但只有兩個不同的日期，日期精確到日；之前有數據50萬條，有5000個不同的日期，日期精確到秒。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-1-1' order by fariqi

用時：6390毫秒

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi<'2004-1-1' order by fariqi

用時：6453毫秒

（五）其他注意事項

「水可載舟，亦可覆舟」，索引也一樣。索引有助於提高檢索性能，但過多或不當的索引也會導致系統低效。因為用戶在表中每加進一個索引，資料庫就要做更多的工作。過多的索引甚至會導致索引碎片。

所以說，我們要建立一個「適當」的索引體系，特別是對聚合索引的創建，更應精益求精，以使您的資料庫能得到高性能的發揮。

當然，在實踐中，作為一個盡職的資料庫管理員，您還要多測試一些方案，找出哪種方案效率最高、最為有效。

二、改善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 ord

『拾』 SQL語句的幾種優化方法

1、盡可能建立索引，包括條件列，連接列，外鍵列等。

2、盡可能讓where中的列順序與復合索引的列順序一致。

3、盡可能不要select *，而只列出自己需要的欄位列表。

4、盡可能減少子查詢的層數。

5、盡可能在子查詢中進行數據篩選 。