mysql 全表掃瞄 mysql的全表掃瞄

在mysql查詢中，如果表沒有索引的話，當查詢執行時，需要從第一行資料到最後一行資料進行全表掃瞄。索引的目的就是輔助查詢能快速定位到目標資料，然後獲取查詢結果。那麼表是否有了索引就一定能加以應用，而不會進行全表掃面了呢？現實肯定不是這樣的!!!

1 全表掃瞄的場景

使用explain分析sql時，當列出執行計畫表中type字段值為all時，代表需要全表掃瞄，全表掃瞄常會發生在以下場景中。

1> 所掃瞄的資料表非常小，因此全表掃瞄的速度要遠快於使用索引，在小於10行或行資料比較短的表中更常見。

2> 在on或where子句中沒有可以使用的索引列。

3> 在使用索引列與常量值比較，並且mysql服務已經通過索引樹計算出常量值覆蓋了大部分表資料，此時使用全表掃瞄是比較快的。

4> 當前正在使用乙個對於其他列來說基數較低的索引(每個索引值在另一列都有多行行對應)，在這種情況下，使用索引可能會引起較多的索引查詢，mysql認為全表掃瞄比較快。

2 避免全表掃瞄

對於小表而言，全表掃瞄因為對效能影響可以忽略所以該方式是最合適的，但是對於大表而言，使用以下操作可以幫助優化器對於是否進行全表掃瞄做出正確的判斷：

1> 使用analyze table tbl_name語句來更新被掃瞄表中索引的分布。

2> 對被掃瞄表使用force index語句來強制優化器對該錶放棄全表掃瞄而使用索引，如下：

3> 設定啟動引數--max-seeks-for-key=1000或使用引數set max_seeks_for_key=1000來通知優化器如果沒有索引掃瞄會導致過千的索引查詢。

3 總結

對於效能開銷忽略不計的小表全表掃瞄我們可以不予重視，但是對於其他情況多是索引設計不合理或應用不合理造成的。

許多資料庫使用人員在遇到sql執行效能不行時，就會狂加一片索引，殊不知，索引帶來的便利性不是依賴於索引個數的，其本質是索引是否正確高效的在應用中發揮作用。對於現實應用中我們新增索引時常常需要考慮多個場景：

1> 該列是否在應用為唯一索引，如果不為唯一索引，重複值的出現概率為多少，如果重複值出現多，是否可以與其他列一起組合成為聯合索引而降低其重複率；

2> 多個單獨應用可能建立了多個索引，對於較大表而言，索引的大小與索引的維護也會對資料庫效能產生重大影響，此時應該考慮是否能夠將應用合併或根據應用特點將索引合併；

3> 表的操作中在insert、update和delete等涉及資料變化的操作中，也會設計到索引的維護。對於表內無效資料定時移除並備份，無效或低效索引的刪除也會提高相關sql語句的效能。