1 模糊查詢效率很低。

like本身效率就比較低，應該儘量避免查詢條件使用like；對於like ‘%...%’（全模糊）這樣的條件，是無法使用索引的，也就是說會進行全表掃描。另外，由於匹配演算法的關係，模糊查詢的欄位長度越大，模糊查詢效率越低。解決方案：1）首先儘量避免模糊查詢，如果因為業務需要一定要使用模糊查詢，則至少保證不要使用全模糊查詢，對於右模糊查詢，即like ‘…%’，是會使用索引的； 左模糊: '%...'無法直接使用索引，但可以利用 like reverse('%321')的形式，變化成 like '123%'；

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

查詢欄位is null時單索引失效，引起全表掃描

解決方案：
1）SQL語法中使用NULL會有很多麻煩，最好索引列都是NOT NULL的；2）對於is null，可以建立組合索引，nvl(欄位,0),對錶和索引分析後，is null查詢時可以重新啟用索引查詢,但是效率還不是值得肯定；3）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 date desc;解決方案：例如：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降序排列。

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

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

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