業務數據LEFT JOIN 多表查詢慢--優化操作

首先你會想到，給表加索引，那么mysql會給主鍵自動建立索引嗎?   

會的，當然會。

在我們查詢的業務表操作的時候，表業務數據龐大起來的時候，以及left join多的時候，甚至多表關聯到幾十張表的時候，查詢是慢到外婆家里去了。

這時候，只需要給表join查詢的字段，及表結構，進行索引優化，即可解決這個慢的問題。

一，首先利用explain 關鍵字對查詢的SQL進行分析。

# type=ALL，全表掃描，MySQL遍歷全表來找到匹配行

# type=index，索引全掃描，MySQL遍歷整個索引來查詢匹配行，並不會掃描表

# type=range，索引范圍掃描，常用於<、<=、>、>=、between等操作

# type=ref，使用非唯一索引或唯一索引的前綴掃描，返回匹配某個單獨值的記錄行

# type=eq_ref，類似ref，區別在於使用的索引是唯一索引，對於每個索引鍵值，表中只有一條記錄匹配

# type=const/system，單表中最多有一條匹配行，查詢起來非常迅速，所以這個匹配行的其他列的值可以被優化器在當前查詢中當作常量來處理

# type=NULL，MySQL不用訪問表或者索引，直接就能夠得到結果

 

 

 

*** 重點來了，為表添加索引，如果發現分析出來的表type 為all ，我們首先想到這個表沒加索引，我們給他加上 ***

 

1.對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引

mysql引擎放棄使用索引而進行全表掃描的幾種情況：

• 應盡量避免在 where 子句中對字段進行 null 值判斷，可以設置默認值0
• 應盡量避免在 where 子句中使用!=或<>操作符
• 應盡量避免在 where 子句中使用or 來連接條件，in 和 not in 也要慎用

• 模糊查詢select id from t where name like ‘%李%’也會全表掃描，若要提高效率，可以考慮全文檢索

• 

   

   

          ------------------添加完后--大功告成----------------------

 

 

MySQL目前主要有以下幾種索引類型：
1.普通索引2.唯一索引3.主鍵索引4.組合索引5.全文索引

mysql Hash索引和BTree索引區別

一、BTree
BTree索引是最常用的mysql數據庫索引算法，因為它不僅可以被用在=,>,>=,<,<=和between這些比較操作符上，而且還可以用於like操作符，只要它的查詢條件是一個不以通配符開頭的常量，例如：
select * from user where name like ‘jack%’;
select * from user where name like ‘jac%k%’;
如果一通配符開頭，或者沒有使用常量，則不會使用索引，例如：
select * from user where name like ‘%jack’;
select * from user where name like simply_name;

一、Hash

1. hash索引查找數據基本上能一次定位數據，當然有大量碰撞的話性能也會下降。而btree索引就得在節點上挨着查找了，很明顯在數據精確查找方面hash索引的效率是要高於btree的；
2. 那么不精確查找呢，也很明顯，因為hash算法是基於等值計算的，所以對於“like”等范圍查找hash索引無效，不支持；
3. 對於btree支持的聯合索引的最優前綴，hash也是無法支持的，聯合索引中的字段要么全用要么全不用。提起最優前綴居然都泛起迷糊了，看來有時候放空得太厲害；
4. hash不支持索引排序，索引值和計算出來的hash值大小並不一定一致。

 

 

 

MySQL是只支持一種JOIN算法Nested-Loop Join（嵌套循環鏈接）   ---   
沒有索引時會走,Block Nested-Loop Join比Simple Nested-Loop Join多了一個中間join buffer緩沖處理的過程

沒有索引時:

 

 

  當關聯字段有索引時,走的是Index Nested-Loop Join(索引嵌套鏈接)  ---

有索引時；