什么樣的字段不適合創(chuàng)建索引呢?同樣,對于有些列不應該創(chuàng)建索引1. 對于那些查詢中很少使用或者參考的列不應該創(chuàng)建索引,就是我查的過程當中,where語句當中沒有,這樣的東西你不建他,建了反而不是什么好事既然在這些列上很少使用,既然在這些列上很少使用,因此有索引和無索引并不能提高查詢速度相反,由于增加了索引,反而降低了系統(tǒng)的維護速度和增大了空間需求,索引見多了還浪費空間,有人說索引不就是存一個值嗎,能有多大,索引在千萬條以上的,你要是索引建多了,輕輕松松索引就可以達到一個G以上,1G可不是1M啊,有人說1G沒事我現(xiàn)在硬盤都1T了,但是1G不只是存索引啊,還有數(shù)據(jù)呢,所以你這么劃分下來隨著數(shù)據(jù)的增長,1T也不夠折騰啊,而且這個空間越大,犧牲的效率就越高,把多塊性能一般的磁盤,通過磁盤陣列的技術(shù),整合成一塊,但是數(shù)據(jù)仍然是分布式的用,根Redis的分片存儲是一樣的,這么做的好處相比你用一塊硬盤,雖然你硬盤數(shù)量上來了2. 對于那些只有很少數(shù)據(jù)值的列,也不需要創(chuàng)建索引,這是因為這些列的取值很少,例如人事表的性別列,在查詢的結(jié)果中,結(jié)果集的數(shù)據(jù)行占了表中數(shù)據(jù)行的很大比例,即需要在表中搜索的數(shù)據(jù)行的比例很大,增加索引,并不能明顯的加快檢索速度所以這樣的也要考慮清楚3. 對于那些定義為text,image和bit數(shù)據(jù)類型的列不應該增加索引,你想想是不是這樣的,text不是大文本嗎,image也是一個大字節(jié),binary不都是大字節(jié)對象嗎,這是因為這些列的數(shù)據(jù)要么相當大,要么取值很少,這些都是不適合建索引的,其實這塊還可以額外的再擴展一些,比如我是做電商的,有一個商品描述,還記得嗎,tb_item_desc,item_desc text,這不是text嗎,這個東西最復雜的地方,淘寶當時在存描述的時候,對于這個字段是老的不親,新的不愛的字段,哪個表都不愿意接受這個字段,為什么,因為這個表存的數(shù)據(jù)量大,在檢索的過程當中,可能因為他的數(shù)據(jù)影響整個效率,確實是這樣的,后來怎么著,其實商品描述是應該在商品信息表里的,因為你本來就屬于我的一部分,后來專門建立一個表,這表什么都不放,只存商品信息,那其實你發(fā)現(xiàn),你在商品存信息的時候,這個信息和商品信息不是一次能夠查出來的,先查商品的基本信息,然后再去查詢商品描述,那讓用戶有更好的體驗效果,還有以前說過,我做開發(fā)的時候,當是我們把海報存到數(shù)據(jù)庫里,后來發(fā)現(xiàn)效率極低,原因就是跟存這個海報有關系,所以速度大而且次數(shù)頻繁,性能就低,后來圖片存在系統(tǒng)的磁盤當中,至少保證數(shù)據(jù)庫的性能不會受太大的影響,所以我們這個例子和他正好是兩種解決方案,它是必須要存到數(shù)據(jù)庫的,因為他是文本,他不是圖片,所以單獨拆分出一張表,而我們是圖片,是直接可以存在文件當中的,那你未來在做項目的時候,如果真的是有這樣的需求,大文本的字段你可以單獨放在一起,因為他是比較容易拉低性能的,像這樣的都不建議建立索引,但不是說他不能建,有一種叫做全文檢索的索引,倒也可以用到上面,一會咱們會說,不是吧所有字段都作為索引的值,比如我把一大串作為索引遍歷4. 索引是為了提高查詢性能,當你這個表的DML語句遠大于查詢,這個表想都不用想,任何字段都不要建索引,那這種策略是什么呢,就是表通過建索引來提高或者優(yōu)化你的查詢性能,而且如果有這樣的需求,通過創(chuàng)建索引來提高查詢,性能會成指數(shù)遞增,真的就是這么神奇,通過建立索引來提升性能,這是好多程序員或者DBA最喜歡用的一個法寶 我們看看MYSQL對于索引的支持,其實MYSQL對于索引的支持,這里提到了一個B-TREE索引,Full-Text索引什么叫B-TREE索引呢?就是所有的索引節(jié)點都按照 Balance Tree,所有的索引數(shù)據(jù)節(jié)點都在葉子節(jié)點,這塊簡單介紹一下,B-TREE什么特點,我簡單畫個圖,這是不是一個典型的樹型數(shù)據(jù)結(jié)構(gòu),樹是不是支持排序的,這是不是一棵樹,[1,2,3,4,5],你可以把它看成索引,咱們再強調(diào)一下,索引會存在什么位置來著,是不是磁盤,文件嗎,他有一個叫磁盤列的東西,一會我就講磁盤列,比如說我現(xiàn)在想找索引為3的節(jié)點,我得對這棵樹進行幾次查找,才能拿到呢,是不是先從5開始找,發(fā)現(xiàn)5下面是4和6,是不是從4節(jié)點往下找,第二次是從4節(jié)點往下找,4節(jié)點下只有2沒有3,是不是要再往下找一次再到2,當我找到2的時候已經(jīng)找了幾次了,3次吧,然后2再往下找會找到3,是不是一共找了4次,也就是對這棵樹遍歷,最壞的情況下需要找4次,是什么引起的必須要找4次呢,是因為樹的階,樹的階是干什么呢,是樹的高度,那最壞的可能是在樹的最底下,高度決定你要找多少次,找4,一次兩次,但是這是對內(nèi)存當中的樹,但是現(xiàn)在索引是存在磁盤里,大家知不知道計算機中有一個叫虛擬內(nèi)存的東西,虛擬內(nèi)存是為了更好的騰出空間的,比如一段時間之內(nèi),內(nèi)存中的數(shù)據(jù)沒用,但是他不敢把它清空,就通過IO把文件讀取,那么我們確認一件事,所以我們有磁盤列,那我是不是要IO四次才能找到,所以說怎么才能解決這個問題呢,B樹就能很好的解決這個問題,B樹是從哪入手的呢,就是我降低你樹的階,就是把這棵樹盡量給你壓扁,降低它的階了,他IO次數(shù)就會少了,那降階怎么降呢,其實你要知道那個公式原理,也就沒那么復雜,其實最終就是什么呢,它的數(shù)據(jù)可以這么存,比如對于1,2,3,4這幾個節(jié)點來講,他可以讓1存在這,然后2,3存到這兒,然后4存到這,再加一個節(jié)點,你要知道B-TREE的最終目的是把一個樹形結(jié)構(gòu)給壓扁,降低它的階,降低階帶來的好處就是降低IO次數(shù),所以這里是一個B-TREE的特點,你要感興趣可以自己取看一看,按照那個公式存儲就可以套進來,也不是什么難的事,所以說MYSQL里面存索引,大部分都是依賴這個B-TREE,我們一會也可以自己建索引,他的索引也是B-TREE類型還有一個叫Full-Text索引,Full-text索引就是我們說的全文檢索,他的結(jié)構(gòu)也是B-TREE形式的,主要是為了解決我們like查詢效率低的問題,主要是針對like,以后會說一下,當然MYSQL里面除了有這些,他還有比如R-TREE,但是那都不是我們要講的內(nèi)容,最重要的是要講B-TREE和Full-TEXT說了這么多了,我們也知道索引的優(yōu)點了,也知道索引的缺點了,知道在那種情況下給哪個字段建索引了,接下來我們的去創(chuàng)建索引我們怎么給一個字段建索引呢,那相比ORACLE來講,MYSQL創(chuàng)建索引那個工具,并沒有像我們的PL/SQL,左側(cè)是羅列出數(shù)據(jù)庫常見對象,里面就有一個index,你直接在可視化的視圖下,就可以給你的表列創(chuàng)建索引,但是MYSQL的navicat沒有提供這樣的工具,那么也就意味著我們還得通過創(chuàng)建索引的命令去創(chuàng)建,好在創(chuàng)建索引的命令并不是很復雜,下面我就做了非常的詳細了

?

總結(jié)

以上是生活随笔為你收集整理的mysql的索引介绍_2的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。