排好序的資料結構
1：如果是二叉樹：
如圖:當字段為有順序遞增時，二叉樹子節點大於父節點原則，二叉樹會無限單邊遞增。這樣高度不可控。查詢效率不高。
2：紅黑樹
紅黑數高度 2的n次方等於資料量，如果資料量為500萬，那麼高度大，查詢次數多，效能不高，而且插入時，節點還自旋。
1：節點資料索引從左到右依次增加。所有索引不重複。
因為每個大節點mysql預設儲存空間為16kb,而每個索引下存了具體的資料。如果表的字段多。那麼乙個大節點存的資料也不是很多，那麼必定會增加高度，那麼查詢次數好是會增多，查詢速度還是不可控
1：非葉子節點不存資料，值存索引（冗餘），可以放更多索引
2：葉子節點包含所有字段資料
3：葉子節點間有雙向指標連線，提高區間訪問效能
當高度為3時，假設data為1kb，指標6b，索引8b
資料量=16kb/8b+6b =1170
117011703 =2千萬條
而且 根節點 是存在記憶體中的，所以根據索引查詢乙個數值要2次
對於等值查詢，hash只要查詢1次就可以了，可是當範圍查詢、排序、模糊查詢hash結構就不能做索引查詢了
4.1 myisam儲存引擎（非聚集索引）
索引檔案和資料檔案分開，葉子節點儲存資料的位址，根據位址去資料檔案查詢資料
4.2 innodb索引實現
1：主鍵索引（聚集索引）
2：葉子節點儲存表所有資料
3：表檔案就是b+tree 組織的乙個索引結構檔案
1：因為innodb資料檔案是b+tree結構組織的索引檔案，而且該檔案非葉子節點儲存都是索引。
2：葉子節點索引大小從左到右依次遞增，如果前面存了許多資料，現在插入一條索引較小的資料時，導致節點會**，需要調整平衡，主鍵自增會減少這種節點**，調整平衡的次數。
3：如果用uuid做主鍵索引，當查詢走索引時，uuid要轉化為整型再做比較，而且uuid消耗儲存空間
為了保證資料一致性，如果非主鍵索引存資料的話，當修改乙個值時，多個檔案多要修改，不好保證資料一致性，也浪費儲存空間。
a,b,c三個字段聯合索引
最左原則：三種走索引情況： a ab abc
注意：1：如果from中包含子查詢，會執行子查詢，並將結果放在記憶體中
2：join連線，explain執行會有兩行記錄
字段含義
idid列的編號是 select 的序列號，有幾個 select 就有幾個id，並且id的順序是按 select 出現的順序增長的,id列越大執行優先順序越高，id相同則從上往下執行，id為null最後執行。
select_type
1:******：簡單查詢 2:primary：複雜查詢中最外層的 select 3:subquery：包含在 select 中的子查詢（不在 from 子句中）4:derived：包含在 from 子句中的子查詢。mysql會將結果存放在乙個臨時表中，也稱為派生表
table
這一列表示 explain 的一行正在訪問哪個表,當 from 子句中有子查詢時，table列是 格式，表示當前查詢依賴 id=n 的查詢，於是先執行 id=n 的查詢。 當有 union 時，union result 的 table 列的值為，1和2表示參與 union 的select 行id
type
這一列表示關聯型別或訪問型別，即mysql決定如何查詢表中的行，查詢資料行記錄的大概範圍。依次從最優到最差分別為：system > const > eq_ref > ref > range > index >all一般來說，得保證查詢達到range級別，最好達到ref
possible_keys
這一列顯示查詢可能使用哪些索引來查詢
key這一列顯示mysql實際採用哪個索引來優化對該錶的訪問
key_len
顯示了mysql在索引裡使用的位元組數，通過這個值可以算出具體使用了索引中的哪些列。(1):字串:char(n)：n位元組長度,varchar(n)：2位元組儲存字串長度，如果是utf-8，則長度 3n+ 2 ( 2):數值型別:tinyint：1位元組,smallint：2位元組,int：4位元組,bigint：8位元組(3:):時間型別: date：3位元組timestamp：4位元組datetime：8位元組…索引最大長度是768位元組，當字串過長時，mysql會做乙個類似左字首索引的處理，將前半部分的字元提取出來做索引。
ref這一列顯示了在key列記錄的索引中，表查詢值所用到的列或常量,常見的有：const（常量），欄位名（例：film.id）
rows
這一列是mysql估計要讀取並檢測的行數，
extra
這一列展示的是額外資訊。(1）using index：使用覆蓋索引 (2）using where：使用 where 語句來處理結果，查詢的列未被索引覆蓋 (3）using index condition：查詢的列不完全被索引覆蓋，(4）using temporary：mysql需要建立一張臨時表來處理查詢。出現這種情況一般是要進行優化的，首先是想到用索引來優化。(5）using filesort：將用外部排序而不是索引排序，資料較小時從記憶體排序，否則需要在磁碟完成排序。這種情況下一般也是要考慮使用索引來優化的。（）6）select tables optimized away：使用某些聚合函式（比如 max、min）來訪問存在索引的某個字段
綜上：1：當type為all時，走全表掃瞄，則需要優化
:2：當extra為using temporary，mysql建立臨時表處理查詢，需要用索引優化
:3：當extra為using filesore ，當資料小的時候是記憶體排序，資料大的時候是磁碟排序，需優化為索引排序
優化sql總結：
最左字首法則
不在索引列上做任何操作（計算、函式、（自動or手動）型別轉換），會導致索引失效而轉向全表掃瞄
儲存引擎不能使用索引中範圍條件右邊的列
盡量使用覆蓋索引（只訪問索引的查詢（索引列包含查詢列）），減少select *語句
mysql在使用不等於（！=或者<>）的時候無法使用索引會導致全表掃瞄
is null,is not null 也無法使用索引
like以萬用字元開頭（』$abc…』）mysql索引失效會變成全表掃瞄操作
字串不加單引號索引失效
少用or或in，用它查詢時，mysql不一定使用索引，mysql內部優化器會根據檢索比例、表大小等多個因素整體評估是否使用索引
mysql多索引結構 MySQL 索引結構詳解
innodb的主鍵索引 primary key 是cluster形式的 聚簇索引 innodb的非主鍵索引 secondary index 是普通的b tree索引。兩種索引在root node和branch node是一樣的，在leaf node就不一樣了。primary key存放的是表的實際資...
MySQL索引結構
b 樹有如下特點 所有鍵值分布在整顆樹中 任何乙個關鍵字出現且只出現在乙個結點中 搜尋有可能在非葉子結點結束 在關鍵字全集內做一次查詢,效能逼近二分查詢 b 樹是b 樹的變體，也是一種多路搜尋樹,它與 b 樹的不同之處在於 所有關鍵字儲存在葉子節點出現,內部節點 非葉子節點並不儲存真正的 data ...
MySQL學習14 查詢分析器explain
分析出表的讀取順序 資料讀取操作的操作型別 哪些索引可以使用 哪些索引被實際使用 表之間的引用 每張表有多少行被優化器查詢。引數描述 id執行select子句或操作表的順序 select type 查詢的型別，如 primary subquery derived union等 table 當前行使用...