資料庫查詢優化藝術

A. 資料庫中查詢優化的一般規律是什麼

1. 查詢檢索的優化首先想到你檢索條件中的欄位是不是索引欄位，不是的話，建立索引

2. 然後是sql語句的優化，select其實就是循環，循環的次數越多，檢索效率越慢，子查詢可以有，但是不要超過三層，超過三層，估計就是檢索sql有問題，要重新梳理邏輯

3. 避免笛卡爾積，幾個表關聯的時候，要用主鍵或者邏輯主鍵去關聯

4. 聚合函數的用法，要注意重復數據的過濾

5. where條件盡量寫詳細，條件越多，就能過濾掉更多的數據，這樣就會提高效率

6. 對於百萬級別或者千萬級別的數據量的檢索，就不是sql優化那麼簡單了，要用到資料庫本身的一些優化機制，有些資料庫帶有臨時表，這是很好的優化方法

7. 存儲過程也是可以優化sql的，一些循環或者條件判斷都可以用存儲過程來實現

純手打。。。。。。。。。。。。。。。。。。。。。。。。。大家可以補充

B. 怎樣優化資料庫查詢怎樣才能提高資料庫的查詢效率

網上有好多這方面的帖子，但我就不去找了。把我知道的幾點給你列一下。
第一點：網速得給力，也就是應用伺服器和資料庫伺服器之間不要做過多限制，特別是防火牆方面的，最好在一個網段
第二點：使用資料庫連接池，無需創建連接，直接查詢
第三點：查詢語句上要明確指定查詢那些列
第四點：連接查詢，嵌套查詢方面要仔細斟酌，選擇最優的方案
第五點：分清各個函數、一些語法的特性，比如要分得清什麼時候用 exists 什麼時候用in
第六點：隨著數據量的增大，再好的語句也會慢下來，可以考慮利用分區
。。。
其他方面還有，可以查看下論壇上的帖子總結一下

C. 怎麼樣操作資料庫的查詢優化技術

在一個關系資料庫中提高和優化查詢方法。很多人都將資料庫看成神奇的聖人，即能夠解決人們提出的各種問題。任何關系資料庫都有一套解決查詢的規則，而各種關系資料庫查詢的過程稍有所區別，但是基本的操作思想和過程是一致的。本文將為你介紹查詢分析器解決查詢的方法和過程。查詢優化的目標在查看分析器查詢的步驟之前，理解查詢優化目標相當重要。顯然，查詢操作的其中一個目標是盡可能地減少使用資源。從資料庫的角度看，這就意味著盡可能地減少I/O操作的次數。在對I/O操作的判斷上，查詢分析器經常做出錯誤的結果。而I/O操作次數必須滿足磁碟的讀取容量。這樣從磁碟I/O讀取的角度看，必須做出合理的選擇條件。索引基於表格的索引是關系資料庫用於解決查詢的重要技術，也是資料庫同時預先將數據分類導入到多表格的方式。通過索引中的欄位和實際數據存放的指針可以完成以上的過程。除了集簇索引（Clustered Index），每一索引的使用都以磁碟容量作為代價。集簇索引是真正意義上與磁碟讀取和磁碟容量代價無關的方法，因為集簇索引是真正按照順序將數據存儲到表格。當使用一個索引，資料庫引擎必須執行兩個數據讀取，這兩個數據讀取是資料庫記錄所必需的。第一個數據被讀取到實際數據指針的索引。第二個數據被讀入到指針指定的位置。此時必須通過資料庫伺服器來查詢，所以考慮系統資源消耗是有必要的。這也是查詢分析器不使用索引的主要原因。在後面的部分中，即Covering Indices，你將學會不使用這兩種讀取的方法——然而，在很多時候使用索引即意味著每一記錄可以完成兩次讀取。統計頁統計頁（Statistics page）是SQL Server用於決定是否使用索引時必需的信息。每一索引都有一個信息表，以將表格所有數據的索引關鍵值分布告訴查詢優化器。統計頁可用於大致估計從一個查詢返回的行數。查詢分析器必須知道返回的行數，由此確定是否值得使用索引方式。如果查詢優化器從索引統計頁中得知將返回幾行，它就會選擇使用索引；如果從統計頁中得知將返回大數量的行數，索引查詢優化器將有可能使用一個表掃描來解決查詢。欄位順序當使用到索引時，欄位順序(Field order)代表眾多欄位的順序。當判斷是否使用索引時，伺服器必須從第一欄位到最後欄位掃描。任何與查詢無關的欄位都將該索引清除掉。當進行索引安排時，你應該將最經常使用到的查詢排列在索引最頂端，不屬於查詢范圍的欄位可以使查詢優化器忽略整個索引。 使用WHERE語句WHERE語句是確定索引的選擇語句的重要組成部分。WHERE語句過濾了顯示記錄的數量，也是查詢優化器查找索引值的最容易的方法。WHERE語句的使用方法有很多種，以下為通常使用到的幾種形式：匹配(相等)WHERE語句最為常用的例子就是一個記錄或多個記錄的匹配。當你指定一個特定欄位等於一個值時，查詢優化器將獲知它要查詢的索引入口，並識別滿足查詢條件的記錄。這就大大地過濾讀取記錄的數量，從而減少查詢所需要的時間。並且，查詢分析器將可找到包含與匹配操作有關的欄位索引的位置。大於或小於雖然匹配和相等是最為普通的選擇方式，而WHERE語句中的查詢范圍要求也是經常見到的。在這種情況下，查詢分析器獲知大於或者小於指定值的索引范圍。通常，查詢分析器可從多個獨立語句中確定被讀取的索引百分含量，並決定是否值得使用索引技術。函數在WHERE語句中使用函數可以限制索引查詢的范圍。查詢分析器的查詢結果難於確定，尤其在執行非常量欄位的時候。所以，使用WHERE語句的函數將盡可能減少查詢次數。使用ORDER BY語句一旦查詢分析器以WHERE語句來判斷，它將以ORDER BY語句而開始查詢。如果查詢優化器找到正確順序行的相應索引，並且這一索引與WHERE條件相符合，優化器將會直接使用到索引技術。為了方便使用索引，ORDER BY語句不應該包含不必要的欄位。查詢分析器不能識別一個欄位的表面意思，而ORDER BY語句可實現按照欄位來排序。由此，如果你的ORDER BY語句中包括欄位，優化器將會找到包含所有這些欄位的索引。在ORDER BY語句中列出每一欄位將有效地阻止查詢優化器使用索引。詳細索引（Covering indices）以上我提到查詢分析器使用索引也會帶來負面，所以有時候我們將不使用索引技術，特別是對於已經確定順序的索引。比如，如果你從一個用戶記錄中選擇User ID,First Name,LastName以及EmailAddress，你可獲得包含所有這些欄位的一個索引，然後查詢分析器可以直接使用索引並讀取數據表。此時，使用一個雙向對照表(cross reference table)將特別有用。你可以在一個方向上使用一個集簇索引，然後在相反方向建立一個帶有欄位的索引。這樣SQL伺服器的第一個方向上可以使用物理表查詢，而在相反方向上使用到索引技術。由於長關鍵字的原因，詳細索引需要額外的空間和更多的時間。然而，如果你有一個參考表，詳細索引能夠有助於查詢分析器更好地工作。幫助查詢優化器當你提交一個查詢之後，查詢分析器的執行都必須通過很多環節。這些環節將有助於快速地獲得結果。然而，通過在查詢中指定你所需要的內容和建立正確的索引，即幫助查詢優化器的操作，以上過程才能順利完成。

D. 網站資料庫查詢如何優化才能達到最佳速度

建議你這樣試試看：

1. 用多少數據就取多少數據原則

2. 減少連表查詢

3. 給資料庫經常查詢的表加索引

4. 優化資料庫結構，減少不必要的查詢

5. 經常使用不經常更新的數據緩存起來
   

這樣做的好處：優化資料庫查詢對於提高網站打開速度、減輕伺服器壓力非常重要。

注意事項：

1、對查詢進行優化,應盡可能避免全表掃描

2、寫數據語句時盡可能減少表的全局掃描

3、不要在條件判斷時進行 算數運算

4、很多時候用 exists 代替 in 是一個好的選擇

5 論索引技巧

E. 《資料庫查詢優化器的藝術原理解析與SQL性能優化》epub下載在線閱讀，求百度網盤雲資源

《資料庫查詢優化器的藝術》（李海翔）電子書網盤下載免費在線閱讀

資源鏈接：

鏈接：

書名：資料庫查詢優化器的藝術

作者：李海翔

豆瓣評分：8.4

出版社：機械工業出版社

出版年份：2014-1-1

頁數：532

內容簡介：

《資料庫技術叢書·資料庫查詢優化器的藝術：原理解析與SQL性能優化》是資料庫查詢優化領域的里程碑之作，由Oracle公司MySQL全球開發團隊、資深專家撰寫，作者有10餘年資料庫內核和查詢優化器研究經驗。資料庫領域泰斗王珊教授親自作序推薦，PostgreSQL中國社區和中國用戶會發起人以及來自Oracle、新浪、網易、華為等企業的數位資深資料庫專家聯袂推薦。從原理角度深度解讀和展示資料庫查詢優化器的技術細節和全貌；從源碼實現角度全方位深入分析MySQL和PostgreSQL兩大主流開源資料庫查詢優化器的實現原理；從工程實踐的角度對比了兩大資料庫的查詢優化器的功能異同和實現異同。它是所有數據開發工程師、內核工程師、DBA以及其他資料庫相關工作人員值得反復研讀的一本書。

《資料庫技術叢書·資料庫查詢優化器的藝術：原理解析與SQL性能優化》共19章，分為四個部分：第一篇（第1～4章）對資料庫查詢優化技術的范圍、邏輯查詢優化、物理查詢優化，以及查詢優化器與其他模塊的關系做了非常細致、深入的講解；第二篇（第5～10章）首先從源碼角度對PostgreSQL查詢優化器的架構、層次、設計思想、相關數據結構和實現原理進行了深入、系統的分析，然後從功能角度對PostgreSQL的邏輯查詢優化、物理查詢優化、查詢優化器的關鍵演算法，以及PostgreSQL查詢優化器與其他模塊的關系做了深入的講解；第三篇（第11～16章）首先從源碼角度對MySQL查詢優化器的架構、層次、設計思想、相關數據結構和實現原理進行了深入、系統的分析，然後從功能角度對MySQL的邏輯查詢優化、物理查詢優化、查詢優化器的關鍵演算法，以及MySQL查詢優化器與其他模塊的關系做了深入的講解；第四篇（第17～19章）對PostgreSQL與MySQL的邏輯查詢優化技術、物理查詢優化技術、設計思想和編碼規范等各方面進行了深度的比較。

作者簡介：

李海翔，網名「那海藍藍」，資深資料庫專家，從事資料庫研發、資料庫測試與技術管理等工作10餘年，對資料庫的內核有深入的研究，長於PostgreSQL和MySQL等開源資料庫的內核與架構。現任職於Oracle公司MySQL全球開發團隊，從事查詢優化技術的研究和MySQL查詢優化器的開發工作。曾參與了863、核高基、工信部、科技部、發改委、北京市科委等多個重大科技項目。2005年獲得北京市科學技術進步獎一等獎，2006年獲高級工程師（系統分析師）。

F. 資料庫查詢優化的策略有哪些

資料庫查詢操作在各種資料庫操作中所佔據的比重最大，而查詢操作所基於的select語句在SQL語句中又是代價最大的語句。舉例來說，如果數據的量積累到一定程度，比如一個銀行的賬戶資料庫表信息積累到上百萬甚至上千條記錄，全表掃描一次往往需要數十分鍾，甚至數小時。如果採用比全表掃描更好的查詢策略，往往可以使查詢時間降為幾分鍾，由此可見查詢優化技術的重要性。

G. 資料庫查詢優化器的藝術哪些人需要了解

基本上可以分成三大類(主流的)：
1.大型資料庫:如Oracle,DB2
2.中型資料庫:如SQLServer,sybase
3.小型資料庫:如MySQL
還有一些（沒什麼人用的）如：VF（foxpro），Access mdb ，infomix ，cloudscape

H. 資料庫查詢性能優化方式有哪些

1、1、調整數據結構的設計。這一部分在開發信息系統之前完成，程序員需要考慮是否使用ORACLE資料庫的分區功能，對於經常訪問的資料庫表是否需要建立索引等。

2、2、調整應用程序結構設計。這一部分也是在開發信息系統之前完成，程序員在這一步需要考慮應用程序使用什麼樣的體系結構，是使用傳統的Client/Server兩層體系結構，還是使用Browser/Web/Database的三層體系結構。不同的應用程序體系結構要求的資料庫資源是不同的。

3、3、調整資料庫SQL語句。應用程序的執行最終將歸結為資料庫中的SQL語句執行，因此SQL語句的執行效率最終決定了ORACLE資料庫的性能。ORACLE公司推薦使用ORACLE語句優化器（Oracle Optimizer）和行鎖管理器（row-level manager）來調整優化SQL語句。

4、4、調整伺服器內存分配。內存分配是在信息系統運行過程中優化配置的，資料庫管理員可以根據資料庫運行狀況調整資料庫系統全局區（SGA區）的數據緩沖區、日誌緩沖區和共享池的大小；還可以調整程序全局區（PGA區）的大小。需要注意的是，SGA區不是越大越好，SGA區過大會佔用操作系統使用的內存而引起虛擬內存的頁面交換，這樣反而會降低系統。

5、5、調整硬碟I/O，這一步是在信息系統開發之前完成的。資料庫管理員可以將組成同一個表空間的數據文件放在不同的硬碟上，做到硬碟之間I/O負載均衡。

6、6、調整操作系統參數，例如：運行在UNIX操作系統上的ORACLE資料庫，可以調整UNIX數據緩沖池的大小，每個進程所能使用的內存大小等參數。

實際上，上述資料庫優化措施之間是相互聯系的。ORACLE資料庫性能惡化表現基本上都是用戶響應時間比較長，需要用戶長時間的等待。但性能惡化的原因卻是多種多樣的，有時是多個因素共同造成了性能惡化的結果，這就需要資料庫管理員有比較全面的計算機知識，能夠敏感地察覺到影響資料庫性能的主要原因所在。另外，良好的資料庫管理工具對於優化資料庫性能也是很重要的。

ORACLE資料庫性能優化工具

常用的資料庫性能優化工具有：

1、1、ORACLE資料庫在線數據字典，ORACLE在線數據字典能夠反映出ORACLE動態運行情況，對於調整資料庫性能是很有幫助的。

2、2、操作系統工具，例如UNIX操作系統的vmstat，iostat等命令可以查看到系統系統級內存和硬碟I/O的使用情況，這些工具對於管理員弄清出系統瓶頸出現在什麼地方有時候很有用。

3、3、SQL語言跟蹤工具（SQL TRACE FACILITY），SQL語言跟蹤工具可以記錄SQL語句的執行情況，管理員可以使用虛擬表來調整實例，使用SQL語句跟蹤文件調整應用程序性能。SQL語言跟蹤工具將結果輸出成一個操作系統的文件，管理員可以使用TKPROF工具查看這些文件。

4、4、ORACLE Enterprise Manager（OEM），這是一個圖形的用戶管理界面，用戶可以使用它方便地進行資料庫管理而不必記住復雜的ORACLE資料庫管理的命令。

5、5、EXPLAIN PLAN——SQL語言優化命令，使用這個命令可以幫助程序員寫出高效的SQL語言。

ORACLE資料庫的系統性能評估

信息系統的類型不同，需要關注的資料庫參數也是不同的。資料庫管理員需要根據自己的信息系統的類型著重考慮不同的資料庫參數。

1、1、在線事務處理信息系統（OLTP），這種類型的信息系統一般需要有大量的Insert、Update操作，典型的系統包括民航機票發售系統、銀行儲蓄系統等。OLTP系統需要保證資料庫的並發性、可靠性和最終用戶的速度，這類系統使用的ORACLE資料庫需要主要考慮下述參數：

l l 資料庫回滾段是否足夠？

l l 是否需要建立ORACLE資料庫索引、聚集、散列？

l l 系統全局區（SGA）大小是否足夠？

l l SQL語句是否高效？

2、2、數據倉庫系統（Data Warehousing），這種信息系統的主要任務是從ORACLE的海量數據中進行查詢，得到數據之間的某些規律。資料庫管理員需要為這種類型的ORACLE資料庫著重考慮下述參數：

l l 是否採用B*-索引或者bitmap索引？

l l 是否採用並行SQL查詢以提高查詢效率？

l l 是否採用PL/SQL函數編寫存儲過程？

l l 有必要的話，需要建立並行資料庫提高資料庫的查詢效率

SQL語句的調整原則

SQL語言是一種靈活的語言，相同的功能可以使用不同的語句來實現，但是語句的執行效率是很不相同的。程序員可以使用EXPLAIN PLAN語句來比較各種實現方案，並選出最優的實現方案。總得來講，程序員寫SQL語句需要滿足考慮如下規則：

1、1、盡量使用索引。試比較下面兩條SQL語句：

語句A：SELECT dname, deptno FROM dept WHERE deptno NOT IN

(SELECT deptno FROM emp);

語句B：SELECT dname, deptno FROM dept WHERE NOT EXISTS

(SELECT deptno FROM emp WHERE dept.deptno = emp.deptno);

這兩條查詢語句實現的結果是相同的，但是執行語句A的時候，ORACLE會對整個emp表進行掃描，沒有使用建立在emp表上的deptno索引，執行語句B的時候，由於在子查詢中使用了聯合查詢，ORACLE只是對emp表進行的部分數據掃描，並利用了deptno列的索引，所以語句B的效率要比語句A的效率高一些。

2、2、選擇聯合查詢的聯合次序。考慮下面的例子：

SELECT stuff FROM taba a, tabb b, tabc c

WHERE a.acol between :alow and :ahigh

AND b.bcol between :blow and :bhigh

AND c.ccol between :clow and :chigh

AND a.key1 = b.key1

AMD a.key2 = c.key2;

這個SQL例子中，程序員首先需要選擇要查詢的主表，因為主表要進行整個表數據的掃描，所以主表應該數據量最小，所以例子中表A的acol列的范圍應該比表B和表C相應列的范圍小。

3、3、在子查詢中慎重使用IN或者NOT IN語句，使用where (NOT) exists的效果要好的多。

4、4、慎重使用視圖的聯合查詢，尤其是比較復雜的視圖之間的聯合查詢。一般對視圖的查詢最好都分解為對數據表的直接查詢效果要好一些。

5、5、可以在參數文件中設置SHARED_POOL_RESERVED_SIZE參數，這個參數在SGA共享池中保留一個連續的內存空間，連續的內存空間有益於存放大的SQL程序包。

6、6、ORACLE公司提供的DBMS_SHARED_POOL程序可以幫助程序員將某些經常使用的存儲過程「釘」在SQL區中而不被換出內存，程序員對於經常使用並且佔用內存很多的存儲過程「釘」到內存中有利於提高最終用戶的響應時間。

CPU參數的調整

CPU是伺服器的一項重要資源，伺服器良好的工作狀態是在工作高峰時CPU的使用率在90％以上。如果空閑時間CPU使用率就在90％以上，說明伺服器缺乏CPU資源，如果工作高峰時CPU使用率仍然很低，說明伺服器CPU資源還比較富餘。

使用操作相同命令可以看到CPU的使用情況，一般UNIX操作系統的伺服器，可以使用sar –u命令查看CPU的使用率，NT操作系統的伺服器，可以使用NT的性能管理器來查看CPU的使用率。

資料庫管理員可以通過查看v$sysstat數據字典中「CPU used by this session」統計項得知ORACLE資料庫使用的CPU時間，查看「OS User level CPU time」統計項得知操作系統用戶態下的CPU時間，查看「OS System call CPU time」統計項得知操作系統系統態下的CPU時間，操作系統總的CPU時間就是用戶態和系統態時間之和，如果ORACLE資料庫使用的CPU時間占操作系統總的CPU時間90％以上，說明伺服器CPU基本上被ORACLE資料庫使用著，這是合理，反之，說明伺服器CPU被其它程序佔用過多，ORACLE資料庫無法得到更多的CPU時間。

資料庫管理員還可以通過查看v$sesstat數據字典來獲得當前連接ORACLE資料庫各個會話佔用的CPU時間，從而得知什麼會話耗用伺服器CPU比較多。

出現CPU資源不足的情況是很多的：SQL語句的重解析、低效率的SQL語句、鎖沖突都會引起CPU資源不足。

1、資料庫管理員可以執行下述語句來查看SQL語句的解析情況：

SELECT * FROM V$SYSSTAT

WHERE NAME IN

('parse time cpu', 'parse time elapsed', 'parse count (hard)');

這里parse time cpu是系統服務時間，parse time elapsed是響應時間，用戶等待時間

waite time = parse time elapsed – parse time cpu

由此可以得到用戶SQL語句平均解析等待時間＝waite time / parse count。這個平均等待時間應該接近於0，如果平均解析等待時間過長，資料庫管理員可以通過下述語句

SELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS FROM V$SQLAREA

ORDER BY PARSE_CALLS;

來發現是什麼SQL語句解析效率比較低。程序員可以優化這些語句，或者增加ORACLE參數SESSION_CACHED_CURSORS的值。

2、資料庫管理員還可以通過下述語句：

SELECT BUFFER_GETS, EXECUTIONS, SQL_TEXT FROM V$SQLAREA;

查看低效率的SQL語句，優化這些語句也有助於提高CPU的利用率。

3、3、資料庫管理員可以通過v$system_event數據字典中的「latch free」統計項查看ORACLE資料庫的沖突情況，如果沒有沖突的話，latch free查詢出來沒有結果。如果沖突太大的話，資料庫管理員可以降低spin_count參數值，來消除高的CPU使用率。

內存參數的調整

內存參數的調整主要是指ORACLE資料庫的系統全局區（SGA）的調整。SGA主要由三部分構成：共享池、數據緩沖區、日誌緩沖區。

1、 1、 共享池由兩部分構成：共享SQL區和數據字典緩沖區，共享SQL區是存放用戶SQL命令的區域，數據字典緩沖區存放資料庫運行的動態信息。資料庫管理員通過執行下述語句：

select (sum(pins - reloads)) / sum(pins) "Lib Cache" from v$librarycache;

來查看共享SQL區的使用率。這個使用率應該在90％以上，否則需要增加共享池的大小。資料庫管理員還可以執行下述語句：

select (sum(gets - getmisses - usage - fixed)) / sum(gets) "Row Cache" from v$rowcache;

查看數據字典緩沖區的使用率，這個使用率也應該在90％以上，否則需要增加共享池的大小。

2、 2、 數據緩沖區。資料庫管理員可以通過下述語句：

SELECT name, value FROM v$sysstat WHERE name IN ('db block gets', 'consistent gets','physical reads');

來查看資料庫數據緩沖區的使用情況。查詢出來的結果可以計算出來數據緩沖區的使用命中率＝1 - ( physical reads / (db block gets + consistent gets) )。

這個命中率應該在90％以上，否則需要增加數據緩沖區的大小。

3、 3、 日誌緩沖區。資料庫管理員可以通過執行下述語句：

select name,value from v$sysstat where name in ('redo entries','redo log space requests');查看日誌緩沖區的使用情況。查詢出的結果可以計算出日誌緩沖區的申請失敗率：

申請失敗率＝requests/entries，申請失敗率應該接近於0，否則說明日誌緩沖區開設太小，需要增加ORACLE資料庫的日誌緩沖區。

I. 資料庫查詢有哪些優化方面

1 SQL查詢語句的重寫，對於一個查詢可以用多種查詢語句實現，但不同查詢語句的資料庫執行計劃是不同的，一旦不能夠使用索引或造成較大的內存佔用會導致性能下降，因此需要對查詢語句進行重寫優化，最典型的例子就是not in語句使用外連接方式實現來進行優化
2 創建合理的索引結構，根據查詢語句的中查詢條件，在關系表上建立相應的索引，如B+樹索引和hash索引
3 修改程序業務邏輯，有些功能如果使用SQL語句實現，不但SQL語句復雜，還將導致資料庫的負擔增加，因此可以將有些數據操作的業務邏輯放到應用層進行實現，就是通過java編程實現
4 修改資料庫伺服器相關參數，優化伺服器性能

J. 如何優化資料庫中數據的查詢

1.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0
2.應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。優化器將無法通過索引來確定將要命中的行數,因此需要搜索該表的所有行。
3.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
4.in 和 not in 也要慎用，因為IN會使系統無法使用索引,而只能直接搜索表中的數據。如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
5.盡量避免在索引過的字元數據中，使用非打頭字母搜索。這也使得引擎無法利用索引。
見如下例子：
SELECT * FROM T1 WHERE NAME LIKE 『%L%』
SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=』L』
SELECT * FROM T1 WHERE NAME LIKE 『L%』
即使NAME欄位建有索引，前兩個查詢依然無法利用索引完成加快操作，引擎不得不對全表所有數據逐條操作來完成任務。而第三個查詢能夠使用索引來加快操作。
6.必要時強制查詢優化器使用某個索引，如在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變數，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：
select id from t where num=@num
可以改為強制查詢使用索引：
select id from t with(index(索引名)) where num=@num
7.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
SELECT * FROM T1 WHERE F1/2=100
應改為:
SELECT * FROM T1 WHERE F1=100*2
SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=』5378』
應改為:
SELECT * FROM RECORD WHERE CARD_NO LIKE 『5378%』
SELECT member_number, first_name, last_name FROM members
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21
應改為:
SELECT member_number, first_name, last_name FROM members
WHERE dateofbirth < DATEADD(yy,-21,GETDATE())
即：任何對列的操作都將導致表掃描，它包括資料庫函數、計算表達式等等，查詢時要盡可能將操作移至等號右邊。
8.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)='abc'--name以abc開頭的id
select id from t where datediff(day,createdate,'2005-11-30')=0--『2005-11-30』生成的id
應改為:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
9.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
10.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致。
11.很多時候用 exists是一個好的選擇：
elect num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)
SELECT SUM(T1.C1)FROM T1 WHERE(
(SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0)
SELECT SUM(T1.C1) FROM T1WHERE EXISTS(
SELECT * FROM T2 WHERE T2.C2=T1.C2)
兩者產生相同的結果，但是後者的效率顯然要高於前者。因為後者不會產生大量鎖定的表掃描或是索引掃描。