一、模糊查詢效率很低：html
緣由：like自己效率就比較低，應該儘可能避免查詢條件使用like；對於like ‘%...%’（全模糊）這樣的條件，是沒法使用索引的，全表掃描天然效率很低；另外，因爲匹配算法的關係，模糊查詢的字段長度越大，模糊查詢效率越低。算法
解決辦法：首先儘可能避免模糊查詢，若是由於業務須要必定要使用模糊查詢，則至少保證不要使用全模糊查詢，對於右模糊查詢，即like ‘…%’，是會使用索引的；左模糊likesql
‘%...’沒法直接使用索引，但能夠利用reverse + function index 的形式，變化成 like ‘…%’；全模糊是沒法優化的，必定要的話考慮用搜索引擎。出於下降服務器的負載考慮，儘量地減小數據庫模糊查詢。數據庫
二、查詢條件中含有is null的select語句執行慢服務器
緣由： 9i中，查詢字段is null時單索引失效，引發全表掃描。性能
解決方法：SQL語法中使用NULL會有不少麻煩，最好索引列都是NOT NULL的；對於is null，能夠創建組合索引，nvl(字段,0),對錶和索引analyse後，is null查詢時能夠從新啓用索引查找,可是效率還不是值得確定；is not null 時永遠不會使用索引。通常數據量大的表不要用is null查詢。大數據
三、查詢條件中使用了不等於操做符（<>、!=）的select語句執行慢優化
緣由：SQL中，不等於操做符會限制索引，引發全表掃描，即便比較的字段上有索引搜索引擎
解決方法：經過把不等於操做符改爲or，可使用索引，避免全表掃描。例如，把column<>’aaa’，改爲column<’aaa’ or column>’aaa’，就可使用索引了。spa
四、使用組合索引，若是查詢條件中沒有前導列，那麼索引不起做用，會引發全表掃描；可是從Oracle9i開始，引入了索引跳躍式掃描的特性，能夠容許優化器使用組合索引，即使索引的前導列沒有出如今WHERE子句中。例如：create index skip1 on emp5(job,empno); 全索引掃描 select count(*) from emp5 where empno=7900; 索引跳躍式掃描 select /*+ index(emp5 skip1)*/ count(*) from emp5 where empno=7900; 前一種是全表掃描，後一種則會使用組合索引。
五、or語句使用不當會引發全表掃描
緣由：where子句中比較的兩個條件，一個有索引，一個沒索引，使用or則會引發全表掃描。例如：where A=：1 or B=：2，A上有索引，B上沒索引，則比較B=：2時會從新開始全表掃描。
六、組合索引，排序時應按照組合索引中各列的順序進行排序，即便索引中只有一個列是要排序的，不然排序性能會比較差。例如：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性能較差。
七、Update 語句，若是隻更改一、2個字段，不要Update所有字段，不然頻繁調用會引發明顯的性能消耗，同時帶來大量日誌。
八、對於多張大數據量（這裏幾百條就算大了）的表JOIN，要先分頁再JOIN，不然邏輯讀會很高，性能不好。
九、select count(*) from table；這樣不帶任何條件的count會引發全表掃描，而且沒有任何業務意義，是必定要杜絕的。
十、sql的where條件要綁定變量，好比where column=：1，不要寫成where column=‘aaa’，這樣會致使每次執行時都會從新分析，浪費CPU和內存資源。
文章來源：http://www.dedecms.com/knowledge/data-base/sql-server/2012/0821/11698.html?jdfwkey=n3nuq
不要看他人高新，且看閒時誰在拼