MySQL之SQL全表掃描有什麼壞處，什麼情況是會導致全表掃描

全表掃描，指的是執行SQL的時候，無法使用索引，導致查詢和執行緩慢。除此之外的壞處是：執行緩慢可能會導致Java程序裏的後續處理被阻塞，降低了 系統的響應速度，同時全表掃描導致了對數據庫資源的耗時佔用，降低了數據庫本身的併發性能。嚴重的會導致使用數據庫的所有應用程序的卡頓。
會引起全表掃描的SQL語句：
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 A=：1 or B=：2，A上有索引，B上沒索引，則比較B=：2時會重新開始全表掃描。
　5、對於多張大數據量(這裏幾百條就算大了)的表JOIN，要先分頁再JOIN，否則邏輯讀會很高，性能很差。
　6.select count(*) from table;這樣不帶任何條件的count會引起全表掃描，並且沒有任何業務意義，是一定要杜絕的。
　7.sql的where條件要綁定變量，比如where column=：1，不要寫成where column=‘aaa’，這樣會導致每次執行時都會重新分析，浪費CPU和內存資源。