Mysql（MyISAM和InnoDB）及Btree和索引優化

MYSQL

1、引擎

mysql：MySQL是一個關係型數據庫管理系統，其中有兩種引擎最爲常見MyISAM和InnoDB

MyISAM（非彙集索引）  　　 MySQL 5.0 以前的默認數據庫引擎，最爲經常使用。擁有較高的插入，查詢速度，但不支持事務

 

InnoDB（彙集索引）  　　 事務型數據庫的首選引擎，支持ACID事務，支持行級鎖定, MySQL 5.5 起成爲默認數據庫引擎

 

 

 

2、MYSQL索引：Btree索引結構。

　　 B-Tree 索引是 MySQL 數據庫中使用最爲頻繁的索引類型，除了 Archive 存儲引擎以外的其餘全部的存儲引擎都支持 B-Tree 索引。

　　 btree索引：通俗點說就是一顆二叉樹

　　   （圖爲百度出來的圖，若有侵權，請私信告訴我。我只是爲了讓Btree更加淺顯易懂，重點是我畫得難看。TOT）

通俗得來講：如取35爲節點，比35小的就放左邊，比35大的就放右邊。若是咱們要尋找87葉子節點的位置，87比35大，因此在右邊，而後87比39還大，因此還在右邊，比65還大，因此還在右邊，一共尋找3次。

Question

說到Btree索引，一直以來都有個通俗問題：對於hash索引， 索引的檢索能夠一次定位，不像B-Tree 索引須要從根節點到枝節點，檢索效率比Btree高不少，那爲何不用Hash索引卻要用Btree索引？

Answer：

有如下幾點緣由： Hash 索引僅僅能知足"=","IN"和"<=>"查詢，不能使用範圍查詢。

　　　　　　　　Hash 索引沒法被用來避免數據的排序操做。

　　　　　　　　Hash 索引在任什麼時候候都不能避免表掃描。

　　　　　　　　Hash 索引遇到大量Hash值相等的狀況後性能並不必定就會比B-Tree索引高。

　　　　　　　　（hash 在mylsam數據表存儲是範圍存放，只按照節點查找，一旦多個hash值索引節點，那麼就要在數據表多個位置尋找，比InnoDB中索引和數據在同一節點尋找複雜得多，因此不推薦hash）（括號的是我總結，不必定對。有錯能夠指出，我會修改）

 

3、彙集索引及其碎片維護

　　（InnoDB）聚簇結構的特色：

• 根據主鍵查詢條目時,不用回行(數據就在主鍵節點下)
• 若是碰到不規則數據插入時,形成頻繁的頁分裂

　　爲何會產生頁分裂？

這是由於聚簇索引採用的是平衡二叉樹算法，並且每一個節點都保存了該主鍵所對應行的數據，假設插入數據的主鍵是自增加的，那麼根據二叉樹算法會很快的把該數據添加到某個節點下，而其餘的節點不用動；可是若是插入的是不規則的數據，那麼每次插入都會改變二叉樹以前的數據狀態。從而致使了頁分裂。

　　優化：

聚簇索引的主鍵值,應儘可能是連續增加的值,而不是要是隨機值, (不要用隨機字符串或UUID)，不然會形成大量的頁分裂與頁移動。在使用InnoDB的時候最好定義成：

id int unsigned primary key auto_increment

 

 

 

 

索引選擇性與前綴索引

由於索引雖然加快了查詢速度，但索引也是有代價的，另外，MySQL在運行時也要消耗資源維護索引，所以索引並非越多越好。

通常兩種狀況下不建議建索引。
1.表記錄比較少，超過2000條能夠酌情考慮索引。
2.索引的選擇性較低。所謂索引的選擇性（Selectivity），是指不重複的索引值（也叫基數，Cardinality）與表記錄數（#T）的比值：
Index Selectivity = Cardinality / #T

顯然選擇性的取值範圍爲(0, 1]，選擇性越高的索引價值越大，這是由B+Tree的性質決定的。

使用索引掃描來優化排序條件
1.索引的列順序和Order by子句的順序徹底一致
2.索引中全部列的方向（升序，降序）和Order by子句徹底一致
3.Order by中的字段所有在關聯表中的第一張表中

 4、MYSQL 優化命令查詢

一、查版本號

不管作什麼都要確認版本號，不一樣的版本號下會有各類差別。

>Select  version();

 

二、執行狀態分析

顯示哪些線程正在運行

>show processlist;   （端口號給我馬賽克了，見諒見諒，安全起見）

　

 

三、Show profile

精確兩位數，小數點。

show profile默認的是關閉的，可是會話級別能夠開啓這個功能，開啓它可讓MySQL收集在執行語句的時候所使用的資源。

分析SQL執行帶來的開銷是優化SQL的經常使用手段，在MySQL數據庫中，能夠經過配置profiling參數來啓用SQL剖析。
它只能在session級別來設置，設置後影響當前session；當它開啓後，後續執行的SQL語句都將記錄其資源開銷，諸如IO，上下文，CPU，MEMORY等。

開啓profiling,有個警告，這個參數在之後會被刪除，用information_scheam.PROFILING替代。

  （設置profiling=1，開啓profile）

  （使用命令：show profile 觀看執行時間，15行受影響）

根據query id查看某個查詢得詳細時間耗時。

 

Explain的列分析

如查詢語句：

查詢語句是explain select * from goods order by goods_id asc \G