A. sql優化器基於規則優化器和基於成本優化器的區別
Oracle有兩種優化器：RBO和CBO。 RBO的最大的問題在於它是靠硬編碼在ORACLE資料庫代碼中的一系列規定的規則來決定目標SQL的執行計劃的，而並沒有考慮目標SQL中所涉及的對象的時間數據量，實際數據分布情況，這樣一旦規定規則並不適用於該SQL中所涉及的實際對象時，RBO根據規定規則產生的執行計劃就很可能不是當前情況下的最優執行計劃了。
下面我們來看如下的例子：
select * from EMP_TEMP where manager_id=100;
假設在EMP_TEMP的manager_id上事先有名為IDX_MGR_TEMP的單鍵值B數索引，如果我們用的是RBO，則不管EMP_TEMP的數據量多大，也不管MANAGER_ID的數據分布如何，ORACLE執行的時候始終會選擇做對IDX_MGR_TEMP的范圍索引掃描，並回表取得EMP_TEMP中的記錄。ORACLE是不會選擇全表掃描EMP_TEMP表的，因為對於RBO而言，全表掃描的等級值要高於索引范圍掃描值的等級值。
RBO的這種選擇在表EMP_TEMP的數據量不大，而且滿足manager_id=10的條件的記錄少的情況下是影響不大的，如果表EMP_TEMP的數據量非常大，例如1000萬條記錄，
而且這1000萬條記錄的MANAGER_ID的值都是100，在這種極端的情況下，如果是RBO,顯然它任然用IDX_MGR_TEMP索引范圍掃描，這個時候性能肯定是很差的。因為相當於以單塊順序掃描所有的1000萬行索引，然後再回表1000萬次。顯然沒有使用多塊以全表掃描方式直接掃描表EMP_TEMP的執行效率高。所以為了解決RBO的這個先天的缺陷，從ORACLE 7開始，ORACLE就引入了CBO。CBO在選擇目標SQL的執行計劃時，是用執行成本作為判斷原則的。CBO會從目標SQL諸多可能的執行路徑中選擇一條成本值最小的執行路徑作為其執行計劃，各條執行路徑的成本是根據目標SQL語句所涉及的表，索引，列等相關對象的統計信息計算出來的。這些信息存儲在ORACLE的資料庫的數據字典里，且從多個維度描述了ORACLE資料庫里相關對象的實際數據量，實際數據分布等詳細信息。
NOTE:ORACLE在對一條執行路徑計算成本時，並不一定從頭到尾完整計算完，只是要ORACLE在計算過程中發現算出來的部分成本值已經大於之前保存下來的到目前為止的最小成本值，就會馬上終止對當前執行路徑成本值的計算，並轉而開始計算下一條新的執行路徑的成本。這個過程會一直持續下去，直到目標SQL的給各個可能的執行路徑全部計算完畢或已經達到預先定義好的待計算的執行路徑數量的閥值。
RBO是根據硬編碼在ORACLE資料庫中來決定目標SQL的執行計劃的，並沒有考慮目標SQL所所涉及的對象的實際數據量，實際分布情況等。而CBO則恰恰相反，它會根據目標SQL的相關的對象的實際數據量，實際數據分布情況的統計信息來決定其執行計劃，即意味著CBO是隨著目標SQL中所涉及的對象的統計信息的變化而變化的。這就意味著只有統計信息相對准確，則用CBO來解析目標SQL會比同等條件下的RBO來解析得到正確執行計劃的概率要高。
當然CBO並不是完美的，它的缺陷主要表現在：
1，CBO會默認目標SQL語句的WHERE條件中出現的各個列之間是獨立的，沒有關系的。
2，CBO會假設所有的目標SQL都是單獨執行的，並且互不幹擾。
3，CBO對直方圖統計信息有諸多限制。
4，CBO在解析多個表關聯的目標SQL時，可能會漏掉正確的執行計劃。
B. SQL 語句優化問題
事實上，這樣的擔心是不必要的。SQL
SERVER中有一個「查詢分析優化器」，它可以計算出WHERE子句中的搜索條件並確定哪個索引能縮小表掃描的搜索空間，也就是說，它能實現自動優化。
雖然查詢優化器可以根據WHERE子句自動的進行查詢優化，但仍然有必要了解一下「查詢優化器」的工作原理，如非這樣，有時查詢優化器就會不按照您的本意進行快速查詢。
在查詢分析階段，查詢優化器查看查詢的每個階段並決定限制需要掃描的數據量是否有用。如果一個階段可以被用作一個掃描參數（SARG），那麼就稱之為可優化的，並且可以利用索引快速獲得所需數據。
SARG的定義：用於限制搜索的一個操作，因為它通常是指一個特定的匹配，一個值得范圍內的匹配或者兩個以上條件的AND連接。形式如下：
列名
操作符
<常數
或
變數>或<常數
或
變數>
操作符列名
列名可以出現在操作符的一邊，而常數或變數出現在操作符的另一邊。如：
Name=』張三』價格>5000
5000<價格
Name=』張三』
and
價格>5000
如果一個表達式不能滿足SARG的形式，那它就無法限制搜索的范圍了，也就是SQL
SERVER必須對每一行都判斷它是否滿足WHERE子句中的所有條件。所以一個索引對於不滿足SARG形式的表達式來說是無用的。
常見的SARG判別經驗：
Like語句是否屬於SARG取決於所使用的通配符的類型
如：name
like
『張%』，這就屬於SARG
而：name
like
『%張』，就不屬於SARG。
原因是通配符%在字元串的開通使得索引無法使用。
or
會引起全表掃描。
Name
=
』張三』
AND
價格>5000，符合SARG，
Name
=
』張三』
OR
價格>5000，不符合SARG。
原因是使用or會引起全表掃描。
非操作符、函數引起的不滿足SARG形式的語句。
不滿足SARG形式的語句最典型的情況就是包括非操作符的語句，如：NOT、!=、<>、!<、!>、NOT
EXISTS、NOT
IN、NOT
LIKE等，另外還有函數。下面就是幾個不滿足SARG形式的例子：
ABS(價格)<5000
Name
like
『%三』
有些表達式，如：WHERE
價格*2>5000
SQL
SERVER也會認為是SARG，SQL
SERVER會將此式轉化為：價格>5000/2
但不推薦這樣使用，因為有時SQL
SERVER不能保證這種轉化與原始表達式是完全等價的。
C. 關於SQL資料庫優化
具體要注意的：
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是一個好的選擇：
select num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select top 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)
兩者產生相同的結果，但是後者的效率顯然要高於前者。因為後者不會產生大量鎖定的表掃描或是索引掃描。
如果你想校驗表裡是否存在某條紀錄，不要用count(*)那樣效率很低，而且浪費伺服器資源。可以用EXISTS代替。如：
IF (SELECT COUNT(*) FROM table_name WHERE column_name = 'xxx')
可以寫成：
IF EXISTS (SELECT * FROM table_name WHERE column_name = 'xxx')
經常需要寫一個T_SQL語句比較一個父結果集和子結果集，從而找到是否存在在父結果集中有而在子結果集中沒有的記錄，如：
SELECT a.hdr_key FROM hdr_tbl a---- tbl a 表示tbl用別名a代替
WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key = b.hdr_key)
SELECT a.hdr_key FROM hdr_tbl a
LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL
SELECT hdr_key FROM hdr_tbl
WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl)
三種寫法都可以得到同樣正確的結果，但是效率依次降低。
12.盡量使用表變數來代替臨時表。如果表變數包含大量數據，請注意索引非常有限（只有主鍵索引）。
13.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
14.臨時表並不是不可使用，適當地使用它們可以使某些常式更有效，例如，當需要重復引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。
15.在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數據量不大，為了緩和系統表的資源，應先create table，然後insert。
16.如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。
17.在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每個語句後向客戶端發送 DONE_IN_PROC 消息。
18.盡量避免大事務操作，提高系統並發能力。
19.盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
20. 避免使用不兼容的數據類型。例如float和int、char和varchar、binary和varbinary是不兼容的。數據類型的不兼容可能使優化器無法執行一些本來可以進行的優化操作。例如:
SELECT name FROM employee WHERE salary > 60000
在這條語句中,如salary欄位是money型的,則優化器很難對其進行優化,因為60000是個整型數。我們應當在編程時將整型轉化成為錢幣型,而不要等到運行時轉化。
21.充分利用連接條件，在某種情況下，兩個表之間可能不只一個的連接條件，這時在 WHERE 子句中將連接條件完整的寫上，有可能大大提高查詢速度。
例：
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO AND A.ACCOUNT_NO=B.ACCOUNT_NO
第二句將比第一句執行快得多。
22、使用視圖加速查詢
把表的一個子集進行排序並創建視圖，有時能加速查詢。它有助於避免多重排序 操作，而且在其他方面還能簡化優化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>「98000」
ORDER BY cust.name
如果這個查詢要被執行多次而不止一次，可以把所有未付款的客戶找出來放在一個視圖中，並按客戶的名字進行排序：
CREATE VIEW DBO.V_CUST_RCVLBES
AS
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
然後以下面的方式在視圖中查詢：
SELECT ＊ FROM V_CUST_RCVLBES
WHERE postcode>「98000」
視圖中的行要比主表中的行少，而且物理順序就是所要求的順序，減少了磁碟I/O，所以查詢工作量可以得到大幅減少。
23、能用DISTINCT的就不用GROUP BY
SELECT OrderID FROM Details WHERE UnitPrice > 10 GROUP BY OrderID
可改為：
SELECT DISTINCT OrderID FROM Details WHERE UnitPrice > 10
24.能用UNION ALL就不要用UNION
UNION ALL不執行SELECT DISTINCT函數，這樣就會減少很多不必要的資源
35.盡量不要用SELECT INTO語句。
SELECT INOT 語句會導致表鎖定，阻止其他用戶訪問該表。
上面我們提到的是一些基本的提高查詢速度的注意事項,但是在更多的情況下,往往需要反復試驗比較不同的語句以得到最佳方案。最好的方法當然是測試，看實現相同功能的SQL語句哪個執行時間最少，但是資料庫中如果數據量很少，是比較不出來的，這時可以用查看執行計劃，即：把實現相同功能的多條SQL語句考到查詢分析器，按CTRL+L看查所利用的索引，表掃描次數（這兩個對性能影響最大），總體上看詢成本百分比即可。
今天在itput上看了一篇文章，是討論一個語句的優化：
原貼地址： http://www.itpub.net/viewthread.php?tid=1015964&extra=&page=1
一，發現問題 優化的語句：
請問以下語句如何優化:
CREATE TABLE aa_001
( ip VARCHAR2(28),
name VARCHAR2(10),
password VARCHAR2(30) )
select * from aa_001 where ip in (1,2,3) order by name desc;
--目前表中記錄有一千多萬條左右，而且in中的值個數是不確定的。
以上就是優化的需要優化的語句和情況。
不少人在後面跟帖：有的說沒辦法優化，有的說將ＩＮ該為ＥＸＩＳＴＳ，有的說在ip上建立索引復合索引（ip，name)等等。
二，提出問題 那這樣的情況，能優化嗎，如何優化？今天就來討論這個問題。
三，分析問題 1，數據量1千萬多條。
2，in中的值個數是不確定
3.1 分析數據分布 這里作者沒有提到ip列的數據的分布情況，目前ip列的數據分布可能有以下幾種：
1，ip列（數據唯一，或者數據重復的概率很小）
2，ip列 (數據不均勻，可能有些數據重復多，有些重復少）
3，ip列 （數據分布比較均勻，數據大量重復，主要就是一些同樣的數據（可能只有上萬級別不同的ip數據等)
解決問題：
1，對於第一種數據分布情況，只要在ip列建立一個索引即可。這時不管表有多少行， in個數是不確定的情況下，都很快。
2，對應第二中數據分布情況，在ip列建立索引，效果不好。因為數據分布不均勻，可能有些快，有些慢
3，對應第三種數據分布情況，在ip列建立索引，速度肯定慢。
注意：這里的 order by name desc 是在取出數據後再排序的。而不是取數據前排序
對於2，3兩個情況，因為都是可能需要取出大量的數據，優化器就採用表掃描(table scan)，而不是索引查找(index seek) ,速度很慢，因為這時表掃描效率要優於索引查找，特別是高並發情況下，效率很低。
那對應2，3中情況，如何處理。是將in改成exists。其實在sql server 2005和oracle里的優化器在in後面數據少時，效率是一樣的。這時採用一般的索引效率很低。這時如果在ip列上建立聚集索引，效率會比較高。我們在SQL server 2005中做個測試。
表：[dbo].[[zping.com]]]中有約200萬條數據。包含列Userid, id, Ruleid等列。按照上面的情況查詢一下類似語句：
select * from [dbo].[[zping.com]]] where
userid in ('',''
,'') order by Ruleid desc
我們先看userid的數據分布情況，執行下面語句：
select userid,count(*) from [dbo].[[zping.com]]] group by userid order by 2
這時我們看看數據分布：總共有379條數據，數據兩從1到15萬都有，數據分布傾斜嚴重。下圖是其中一部分。
這時如果在ip上建立非聚集索引，效率很低，而且就是強行索引掃描，效率也很低，會發現IO次數比表掃描還高。這時只能在ip上建立聚集索引。這時看看結果。
這時發現，搜索採用了（clustered index seek）聚集搜索掃描。
在看看查詢返回的結果：
(156603 行受影響)
表 '[zping.com]'。掃描計數 8，邏輯讀取 5877 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
表 'Worktable'。掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
返回15萬行，才不到6千次IO。效率較高，因為這15萬行要排序，查詢成本里排序佔了51%。當然可以建立（userid，Ruleid）復合聚集索引，提高性能，但這樣做DML維護成本較高。建議不採用。
從上面的測試例子可以看出， 優化的解決辦法：
數據分布為1：建立ip索引即可
數據分布為2，3：在ip列建立聚集索引。
D. 怎樣進行sql資料庫的優化
1、資料庫空間是個概述，在sqlserver里，使用語句 exec sp_spaceused 'TableName' 這個語句來查。
E. 資料庫系統優化的人工智慧自動SQL優化
人工智慧自動SQL優化出現在90年代末。目前在商用資料庫領域，LECCO Technology Limited(靈高科研有限公司)擁有該技術，並提供使用該技術的自動優化產品LECCO SQL Expert，它支持Oracle、Sybase、MS SQL Server和IBM DB2資料庫平台。該產品針對資料庫應用的開發和維護階段提供的模塊有：SQL語法優化器、PL/SQL集成化開發調試環境(IDE)、掃描器、資料庫監視器等。其核心模塊SQL 語法優化器的工作原理為：①輸入一條源SQL語句；②「人工智慧反饋式搜索引擎」對輸入的SQL語句，結合檢測到的資料庫結構和索引進行重寫，產生N條等效的SQL語句輸出；③產生的N條等效SQL語句再送入「人工智慧反饋式搜索引擎」進行重寫，直至無法產生新的輸出或搜索限額滿；④對輸出的SQL語句進行過濾，選出具有不同執行計劃的SQL語句；⑤對得到的SQL語句進行批量測試，找出性能最好的SQL語句。
F. SQL查詢優化、SQL執行計劃及優化器之間什麼關系
一，SQL查詢優化：指，使用的語句是不是冗餘的，就是有沒有無用的。
你可用用explain 你的語句來比較分板一番。比如：select * from wc where 1;與select * from wc二者的執行時間不一樣的；
二，SQL執行計劃就是用於描述SQL引擎在執行一個sql語句時的所有步驟，通過執行計劃，我們可以知道哪個表是驅動表，如何訪問一個表：是通過索引訪問還是通過表掃描，如何進行連接：使用嵌套連接，合並連接還是哈希連接，連接的順序等等；
在我們處理執行計劃的過程中，一般有三個步驟：
獲取執行計劃
理解執行計劃
判斷其效率
2.獲取執行計劃的方式
Oracle提供了以下幾種方法獲得sql語句的執行計劃：
2.1 explain plan
這種方法用於給出當前的sql文本的評估的執行計劃，oracle並不會執行相應的sql語句，而且如果sql語句有綁定參數，那麼得到的執行計劃並不一定就是確切的執行計劃，還要根據條件中的列是否有直方圖和cursor_sharing參數的配置值來判斷。
a. 在sqlplus 中執行explain plan
SQL>Explain plan set sql_id=』mysql』 for select * from temp;
b. 使用dbms_xplan顯示執行計劃
select * from table(dbms_xplan.display());
或者：select * from table(dbms_xplan.display(statement_id => 『mysql』));
三，優化器；是SQL執行效率的重構工具。
可以幫助將低效率的SQL優化成為高效率的。
一般主要針對查詢語句。
將更多的判斷條件已到葉子節點上去操作。
G. 如何優化sql語句
一、問題的提出
在應用系統開發初期，由於開發資料庫數據比較少，對於查詢SQL語句，復雜視圖的的編寫等體會不出SQL語句各種寫法的性能優劣，但是如果將應用系統提交實際應用後，隨著資料庫中數據的增加，系統的響應速度就成為目前系統需要解決的最主要的問題之一。系統優化中一個很重要的方面就是SQL語句的優化。對於海量數據，劣質SQL語句和優質SQL語句之間的速度差別可以達到上百倍，可見對於一個系統不是簡單地能實現其功能就可，而是要寫出高質量的SQL語句，提高系統的可用性。
在多數情況下，Oracle使用索引來更快地遍歷表，優化器主要根據定義的索引來提高性能。但是，如果在SQL語句的where子句中寫的SQL代碼不合理，就會造成優化器刪去索引而使用全表掃描，一般就這種SQL語句就是所謂的劣質SQL語句。在編寫SQL語句時我們應清楚優化器根據何種原則來刪除索引，這有助於寫出高性能的SQL語句。
二、SQL語句編寫注意問題
下面就某些SQL語句的where子句編寫中需要注意的問題作詳細介紹。在這些where子句中，即使某些列存在索引，但是由於編寫了劣質的SQL，系統在運行該SQL語句時也不能使用該索引，而同樣使用全表掃描，這就造成了響應速度的極大降低。
1. IS NULL 與 IS NOT NULL
不能用null作索引，任何包含null值的列都將不會被包含在索引中。即使索引有多列這樣的情況下，只要這些列中有一列含有null，該列就會從索引中排除。也就是說如果某列存在空值，即使對該列建索引也不會提高性能。
任何在where子句中使用is null或is not null的語句優化器是不允許使用索引的。
2. 聯接列
對於有聯接的列，即使最後的聯接值為一個靜態值，優化器是不會使用索引的。我們一起來看一個例子，假定有一個職工表(employee)，對於一個職工的姓和名分成兩列存放(FIRST_NAME和LAST_NAME)，現在要查詢一個叫比爾.柯林頓(Bill Cliton)的職工。
下面是一個採用聯接查詢的SQL語句，
select * from employss where first_name||''||last_name ='Beill Cliton';
上面這條語句完全可以查詢出是否有Bill Cliton這個員工，但是這里需要注意，系統優化器對基於last_name創建的索引沒有使用。
當採用下面這種SQL語句的編寫，Oracle系統就可以採用基於last_name創建的索引。
*** where first_name ='Beill' and last_name ='Cliton';
. 帶通配符(%)的like語句
同樣以上面的例子來看這種情況。目前的需求是這樣的，要求在職工表中查詢名字中包含cliton的人。可以採用如下的查詢SQL語句:
select * from employee where last_name like '%cliton%';
這里由於通配符(%)在搜尋詞首出現，所以Oracle系統不使用last_name的索引。在很多情況下可能無法避免這種情況，但是一定要心中有底，通配符如此使用會降低查詢速度。然而當通配符出現在字元串其他位置時，優化器就能利用索引。在下面的查詢中索引得到了使用:
select * from employee where last_name like 'c%';
4. Order by語句
ORDER BY語句決定了Oracle如何將返回的查詢結果排序。Order by語句對要排序的列沒有什麼特別的限制，也可以將函數加入列中(象聯接或者附加等)。任何在Order by語句的非索引項或者有計算表達式都將降低查詢速度。
仔細檢查order by語句以找出非索引項或者表達式，它們會降低性能。解決這個問題的辦法就是重寫order by語句以使用索引，也可以為所使用的列建立另外一個索引，同時應絕對避免在order by子句中使用表達式。
5. NOT
我們在查詢時經常在where子句使用一些邏輯表達式，如大於、小於、等於以及不等於等等，也可以使用and(與)、or(或)以及not(非)。NOT可用來對任何邏輯運算符號取反。下面是一個NOT子句的例子:
... where not (status ='VALID')
如果要使用NOT，則應在取反的短語前面加上括弧，並在短語前面加上NOT運算符。NOT運算符包含在另外一個邏輯運算符中，這就是不等於(<>)運算符。換句話說，即使不在查詢where子句中顯式地加入NOT詞，NOT仍在運算符中，見下例:
... where status <>'INVALID';
對這個查詢，可以改寫為不使用NOT:
select * from employee where salary<3000 or salary>3000;
雖然這兩種查詢的結果一樣，但是第二種查詢方案會比第一種查詢方案更快些。第二種查詢允許Oracle對salary列使用索引，而第一種查詢則不能使用索引。
雖然這兩種查詢的結果一樣，但是第二種查詢方案會比第一種查詢方案更快些。第二種查詢允許Oracle對salary列使用索引，而第一種查詢則不能使用索引。