本篇文章我們來(lái)了解下數(shù)據(jù)庫(kù)索引，首先什么是數(shù)據(jù)庫(kù)索引均函？
數(shù)據(jù)庫(kù)索引 是為了加快查詢速度對(duì)表的字段增加的一種標(biāo)識(shí)升熊。DB在執(zhí)行sql語(yǔ)句的時(shí)候沃于，如果沒(méi)有索引涩咖，將會(huì)根據(jù)搜索條件進(jìn)行全局遍歷海诲，如果對(duì)某一字段增加索引，會(huì)根據(jù)索引定位數(shù)據(jù)具體所在的位置檩互，減少了查找的次數(shù)特幔，加快了操作速度。索引的實(shí)現(xiàn)通常使用B樹(shù)及其變種B+樹(shù)闸昨。
創(chuàng)建索引可以大大提高系統(tǒng)的性能:
1.通過(guò)創(chuàng)建唯一性索引蚯斯，可以保證數(shù)據(jù)庫(kù)表中每一行數(shù)據(jù)的唯一性。
2.可以大大加快數(shù)據(jù)的檢索速度饵较，這也是創(chuàng)建索引的最主要的原因拍嵌。
3.可以加速表和表之間的連接，特別是在實(shí)現(xiàn)數(shù)據(jù)的參考完整性方面特別有意義循诉。
4.在使用分組和排序子句進(jìn)行數(shù)據(jù)檢索時(shí)横辆，同樣可以顯著減少查詢中分組和排序的時(shí)間。
5.通過(guò)使用索引茄猫，可以在查詢的過(guò)程中狈蚤，使用優(yōu)化隱藏器，提高系統(tǒng)的性能划纽。
但也有一些不利的地方:
1.創(chuàng)建索引和維護(hù)索引要耗費(fèi)時(shí)間脆侮，這種時(shí)間隨著數(shù)據(jù)量的增加而增加。
2.索引需要占物理空間勇劣，除了數(shù)據(jù)表占數(shù)據(jù)空間之外靖避，每一個(gè)索引還要占一定的物理空間，如果要建立聚簇索引比默，那么需要的空間就會(huì)更大幻捏。
3.當(dāng)對(duì)表中的數(shù)據(jù)進(jìn)行增加、刪除和修改的時(shí)候退敦，索引也要?jiǎng)討B(tài)的維護(hù)粘咖，這樣就降低了數(shù)據(jù)的維護(hù)速度蚣抗。
索引是建立在數(shù)據(jù)庫(kù)表中的某些列的上面侈百。在創(chuàng)建索引的時(shí)候，應(yīng)該考慮在哪些列上可以創(chuàng)建索引翰铡，在哪些列上不能創(chuàng)建索引钝域。一般來(lái)說(shuō)，應(yīng)該在這些列上創(chuàng)建索引:
1.在經(jīng)常需要搜索的列上锭魔，可以加快搜索的速度例证；
2.在作為主鍵的列上，強(qiáng)制該列的唯一性和此列的物理排列結(jié)構(gòu)迷捧；
3.在經(jīng)常用在連接的列上织咧，這些列主要是一些外鍵胀葱，可以加快連接的速度；
4.在經(jīng)常需要根據(jù)范圍進(jìn)行搜索的列上創(chuàng)建索引笙蒙，因?yàn)樗饕呀?jīng)排序抵屿，其指定的范圍是連續(xù)的；
5.在經(jīng)常需要排序的列上創(chuàng)建索引捅位，因?yàn)樗饕呀?jīng)排序轧葛，這樣查詢可以利用索引的排序，加快排序查詢時(shí)間艇搀；
6.在經(jīng)常使用在WHERE子句中的列上面創(chuàng)建索引尿扯，加快條件的判斷速度。
也有不適合創(chuàng)建索引的列:
1.對(duì)于那些在查詢中很少使用或者參考的列不應(yīng)該創(chuàng)建索引焰雕。這是因?yàn)橹运瘢热贿@些列很少使用到，因此有索引或者無(wú)索引淀散，并不能提高查詢速度右莱。相反，由于增加了索引档插，反而降低了系統(tǒng)的維護(hù)速度和增大了空間需求慢蜓。
2.對(duì)于那些只有很少數(shù)據(jù)值的列也不應(yīng)該增加索引。這是因?yàn)楣牛捎谶@些列的取值很少晨抡，例如人事表的性別列，在查詢的結(jié)果中则剃，結(jié)果集的數(shù)據(jù)行占了表中數(shù)據(jù)行的很大比例耘柱，即需要在表中搜索的數(shù)據(jù)行的比例很大。增加索引棍现，并不能明顯加快檢索速度调煎。
3.對(duì)于那些定義為image和bit數(shù)據(jù)類(lèi)型的列不應(yīng)該增加索引。這是因?yàn)榧喊梗@兩種類(lèi)型數(shù)據(jù)量要么相當(dāng)大士袄，要么取值很少。
4.當(dāng)修改性能遠(yuǎn)遠(yuǎn)大于檢索性能時(shí)谎僻，不應(yīng)該創(chuàng)建索引娄柳。這是因?yàn)椋薷男阅芎蜋z索性能是互相矛盾的艘绍。當(dāng)增加索引時(shí)赤拒，會(huì)提高檢索性能，但是會(huì)降低修改性能。當(dāng)減少索引時(shí)挎挖，會(huì)提高修改性能这敬，降低檢索性能。因此蕉朵，當(dāng)修改性能遠(yuǎn)遠(yuǎn)大于檢索性能時(shí)鹅颊，不應(yīng)該創(chuàng)建索引。
數(shù)據(jù)庫(kù)索引可以分為主鍵索引墓造、唯一索引堪伍、普通索引、組合索引觅闽、全文索引(MySQL 5.6 以前的版本帝雇，只有 MyISAM 存儲(chǔ)引擎支持全文索引，MySQL 5.6 及以后的版本蛉拙，MyISAM 和 InnoDB 存儲(chǔ)引擎均支持全文索引)尸闸。這個(gè)就不詳細(xì)介紹了，相信大家都比較熟孕锄。
從另一種角度吮廉，索引也可以分為聚集索引和非聚集索引，聚集索引是指數(shù)據(jù)庫(kù)表行中數(shù)據(jù)的物理順序與鍵值的邏輯(索引)順序相同畸肆，也就是說(shuō)該索引中鍵值的邏輯順序決定了表中相應(yīng)行的物理順序宦芦，所以一張表中只能有一個(gè)聚集索引，mysql中轴脐，聚集索引通常是主鍵索引调卑，若無(wú)主鍵則為表中第一個(gè)非空的唯一索引，還是沒(méi)有就采用innodb存儲(chǔ)引擎為每行數(shù)據(jù)內(nèi)置的ROWID作為聚集索引大咱。
mysql的存儲(chǔ)引擎分為myisam和innodb:
- myisam是mysql默認(rèn)的引擎恬涧，但是它沒(méi)有提供對(duì)數(shù)據(jù)庫(kù)事務(wù)的支持，也不支持行級(jí)鎖和外鍵碴巾，因此當(dāng)insert(插入)或update(更新)數(shù)據(jù)時(shí)即寫(xiě)操作需要鎖定整個(gè)表溯捆，效率便會(huì)低一些。不過(guò)和innodb不同厦瓢，myisam中存儲(chǔ)了表的行數(shù)提揍，于是select count(*) from table時(shí)只需要直接讀取已經(jīng)保存好的值而不需要進(jìn)行全表掃描。如果表的讀操作遠(yuǎn)遠(yuǎn)多于寫(xiě)操作且不需要數(shù)據(jù)庫(kù)事務(wù)的支持旷痕，那么myisam也是很好的選擇碳锈。
- innodb引擎提供了對(duì)數(shù)據(jù)庫(kù)ACID事務(wù)的支持顽冶，并且實(shí)現(xiàn)了SQL標(biāo)準(zhǔn)的四種隔離級(jí)別欺抗。該引擎還提供了行級(jí)鎖和外鍵約束，它的設(shè)計(jì)目標(biāo)是處理大容量數(shù)據(jù)庫(kù)系統(tǒng)强重。當(dāng)需要使用數(shù)據(jù)庫(kù)事務(wù)時(shí)绞呈，該引擎當(dāng)然是首選贸人。由于鎖的粒度更小，寫(xiě)操作不會(huì)鎖定全表佃声，所以在并發(fā)較高時(shí)艺智，使用innodb引擎會(huì)提升效率。但是使用行級(jí)鎖也不是絕對(duì)的圾亏，如果在執(zhí)行一個(gè)SQL語(yǔ)句時(shí)MySQL不能確定要掃描的范圍十拣，innodb表同樣會(huì)鎖全表。
局部性原理
由于存儲(chǔ)介質(zhì)的特性志鹃，磁盤(pán)本身存取就比主存慢很多夭问，再加上機(jī)械運(yùn)動(dòng)耗費(fèi)，磁盤(pán)的存取速度往往是主存的幾百分分之一曹铃，因此為了提高效率缰趋，要盡量減少磁盤(pán)I/O。為了達(dá)到這個(gè)目的陕见，磁盤(pán)往往不是嚴(yán)格按需讀取秘血，而是每次都會(huì)預(yù)讀，即使只需要一個(gè)字節(jié)评甜，磁盤(pán)也會(huì)從這個(gè)位置開(kāi)始灰粮，順序向后讀取一定長(zhǎng)度的數(shù)據(jù)放入內(nèi)存。這樣做的理論依據(jù)是計(jì)算機(jī)科學(xué)中著名的局部性原理：當(dāng)一個(gè)數(shù)據(jù)被用到時(shí)忍坷，其附近的數(shù)據(jù)也通常會(huì)馬上被使用谋竖。程序運(yùn)行期間所需要的數(shù)據(jù)通常比較集中。
預(yù)讀的長(zhǎng)度一般為頁(yè)（page）的整倍數(shù)承匣。頁(yè)是計(jì)算機(jī)管理存儲(chǔ)器的邏輯塊蓖乘，硬件及操作系統(tǒng)往往將主存和磁盤(pán)存儲(chǔ)區(qū)分割為連續(xù)的大小相等的塊，每個(gè)存儲(chǔ)塊稱為一頁(yè)（在許多操作系統(tǒng)中韧骗，頁(yè)得大小通常為4k）嘉抒，主存和磁盤(pán)以頁(yè)為單位交換數(shù)據(jù)。
索引的數(shù)據(jù)結(jié)構(gòu)
mysql索引使用B+樹(shù)結(jié)構(gòu)而不是B樹(shù)袍暴，因?yàn)锽樹(shù)只適合隨機(jī)檢索些侍，而B(niǎo)+樹(shù)同時(shí)支持隨機(jī)檢索和順序檢索，同時(shí)B+樹(shù)空間利用率更高政模，因?yàn)锽+樹(shù)的內(nèi)部節(jié)點(diǎn)（非葉子節(jié)點(diǎn)岗宣，也稱索引節(jié)點(diǎn)）不存儲(chǔ)數(shù)據(jù)，只存儲(chǔ)索引值淋样，相比較B樹(shù)來(lái)說(shuō)耗式，B+樹(shù)一個(gè)節(jié)點(diǎn)可存儲(chǔ)更多的索引值，使得整顆B+樹(shù)變得更矮，減少I(mǎi)/O次數(shù)刊咳，磁盤(pán)讀寫(xiě)代價(jià)更低彪见，I/O讀寫(xiě)次數(shù)是影響索引檢索效率的最大因素。通常InnoDB的一棵B+樹(shù)可以存放約2千萬(wàn)行數(shù)據(jù)(通過(guò)網(wǎng)友計(jì)算得出)娱挨，
索引失效的幾種情況：
1.當(dāng)查詢條件存在隱式轉(zhuǎn)換時(shí)余指，索引會(huì)失效，比如列類(lèi)型是字符串跷坝，查詢條件未加引號(hào)
2.使用like時(shí)通配符在前
3.在查詢條件中使用OR酵镜，查詢條件中使用or會(huì)使索引失效，要想使索引生效柴钻，需要將or中的每個(gè)列都加上索引笋婿。
4.對(duì)索引列進(jìn)行函數(shù)運(yùn)算
5.聯(lián)合索引時(shí)，一個(gè)查詢可以只使用索引中的一部份顿颅，但只能是最左側(cè)部分缸濒，不支持只使用非左側(cè)部分。
6.not條件粱腻，當(dāng)查詢條件為非時(shí)庇配，索引定位會(huì)比較困難，執(zhí)行計(jì)劃此時(shí)可能更傾向于全表掃描绍些，這類(lèi)的查詢條件有：<>捞慌、NOT、in柬批、not exists啸澡。
7.存在NULL值條件，如果索引列是可空的氮帐，很可能是不會(huì)給其建索引的嗅虏，索引值是少于表的count(*)值的，所以這種情況下上沐，執(zhí)行計(jì)劃自然就去掃描全表了皮服。
引用：
https://blog.csdn.net/weixin_44893585/article/details/104695350
https://blog.csdn.net/kennyrose/article/details/7532032
https://www.zhihu.com/question/20596402/answer/977935094
