之前總結(jié)過 B/B+ 樹和 MySQL 相關(guān)知識點，那邊文章最后也簡單介紹了建立索引需要注意的地方，考慮到數(shù)據(jù)庫索引在實際應(yīng)用中的重要性，也是面試題目的重要考察點，還是考慮更完整，更系統(tǒng)的學(xué)習(xí)總結(jié)下
關(guān)于索引
在數(shù)據(jù)庫中，對無索引的表進行查詢一般稱為全表掃描。全表掃描是數(shù)據(jù)庫服務(wù)器會讀取表中所有行，并檢查每一行是否滿足語句的限制條件，直到找到所有符合給定條件的記錄返回為止。
索引掃描利用索引在存儲結(jié)構(gòu)中已經(jīng)進行排序的特性，只需掃描一部分數(shù)據(jù)就可以得到結(jié)果。在數(shù)據(jù)量不大的情況下，全表掃描和索引掃描的性能差距不是很大。因為索引也會占用硬盤資源，如果索引所占的空間大于數(shù)據(jù)的話，很可能全表掃描性能更好。
對于任何DBMS，索引都是進行優(yōu)化的最主要的因素。對于少量的數(shù)據(jù)，沒有合適的索引影響不是很大，但是，當(dāng)隨著數(shù)據(jù)量的增加，性能會急劇下降。
索引備選列
用于索引的備選數(shù)據(jù)列一般是那些出現(xiàn)在 WHERE，JOIN，ORDER BY 或者 GROUP BY 子句中的列。比如：
SELECT
col_a <- 不是備選列
FROM
tbl1 LEFT JOIN tbl2
ON tbl1.col_b = tbl2.col_c <- 備選列
WHERE
col_d = expr; <- 備選列
選擇索引
盡量使用整型字段
若只含數(shù)值信息的字段盡量不要設(shè)計為字符型，這會降低查詢和連接的性能，并會增加存儲開銷。
- 整型數(shù)據(jù)比起字符，處理開銷更小。在比較字符串時，引擎會逐個比較字符串中的每一個字符，而對于整型，只需要比較一次就夠了；
- 整型只需要 4 個 byte，而字符串一般不止這么多。索引一般以 B+ 樹存儲在硬盤上，索引空間比較小，意味著硬盤一個頁可以存儲更多的索引。通過預(yù)讀等技術(shù)，數(shù)據(jù)庫可以用更少的硬盤尋道時間讀取更多索引，減少 IO 時間。
選擇高區(qū)分度索引
區(qū)分度表示字段不重復(fù)的比例，公式為： count(distinct col)/count(*)。區(qū)分度越高說明掃描的記錄越少，唯一鍵的區(qū)分度是 1。這個區(qū)分度有經(jīng)驗值么？使用場景不同，這個值很難確定，一般需要 JOIN 的字段，區(qū)分度要求 0.1 以上。
前綴索引
選擇長度較短的字段原因和盡量使用整型類似，主要也是由計算復(fù)雜度和存儲空間考慮。如果索引字段為字符串，而且前面 n 個字符都不同，就不需要索引整個數(shù)據(jù)列，只索引前 n 個字符就可以了。在索引 CHAR、VARCHAR、BINARY、VARBINARY、BLOB和TEXT數(shù)據(jù)列時可以嘗試前綴索引。
最左前綴匹配原則
最左前綴匹配原則主要用在復(fù)合索引的使用。假設(shè)有張表，其中 (name, cid) 為例，它內(nèi)部結(jié)構(gòu)簡單如下排列：
MySQL 創(chuàng)建復(fù)合索引的規(guī)則是首先會對復(fù)合索引的最左邊的，也就是第一個 name 字段的數(shù)據(jù)進行排序，在第一個字段的排序基礎(chǔ)上，然后再對后面第二個的 cid 字段進行排序。所以第一個 name 字段是絕對有序的，而第二字段就是無序的了。所以通常情況下，直接使用第二個 cid 字段進行條件判斷是用不到索引的。
更進一步，如果復(fù)合索引為 (name, cid, zid)，意味著這個索引可以被用于檢索一下數(shù)據(jù)列組合：
- name, cid, zid
- name, cid
- name
范圍查詢
MySQL 在查詢復(fù)合索引時，使用最左前綴匹配原則，知道遇到范圍查詢就停止匹配。范圍查詢?nèi)纾?lt;，>，BETWEENT，LIKE。比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)順序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引則都可以用到，a,b,d的順序可以任意調(diào)整。
盡量避免
即使設(shè)置了索引，但是在不當(dāng)檢索下，還是為進行全表掃描或者索引性能不佳的情況，應(yīng)該盡量避免以下幾種情況：
1. 索引列不要參與計算，保持“干凈”
比如 from_unixtime(create_time) = '2014-05-29' 就不能使用到索引，原因很簡單，B+ 樹中存的都是數(shù)據(jù)表中的字段值，但進行檢索時，需要把所有元素都應(yīng)用函數(shù)才能比較，顯然成本太大。所以語句應(yīng)該寫成 create_time = unix_timestamp( '2014-05-29' )。
2. 避免 NULL 值判斷
應(yīng)盡量避免在 WHERE 子句中對字段進行 null 值判斷，否則將導(dǎo)致引擎放棄使用。
索引而進行全表掃描。
3. 避免使用 OR 連接條件，可以用 UNION
應(yīng)盡量避免在 where 子句中使用 or 來連接條件，否則將導(dǎo)致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10 union all select id from t where num=20
4. LIKE 查詢時避免前置 %，這種模糊查詢也能導(dǎo)致全表檢索，若要提高效率，可以考慮全文檢索。
5. 慎用 IN 和 NOT IN，對于連續(xù)的值可以考慮用 BETWEEN 代替 IN 和 NOT IN
內(nèi)容來源
http://mp.weixin.qq.com/s/KsXS5f-1-217CY5R88qOHQ
https://www.zhihu.com/question/36996520?sort=created
http://blog.csdn.net/zhanglu0223/article/details/8713149
http://www.cnblogs.com/hustcat/archive/2009/10/28/1591648.html
