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 A1 or B2，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會引起全表掃描，并且沒有任何業務意義，是一定要杜絕的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/205103.html
標籤：其他
下一篇：DataGrip的簡單設定及使用