最近再看mysql技術(shù)內(nèi)部+innoDb存儲引擎一書，書中第五章-索引與算法中講到?查看表的索引信息中的一些參數(shù)含義，特作記錄

show?index?from table_name ##? 查看該表的索引信息

table?索引所在表名

Non_unique? ：非唯一的索引，可以看到primary_key是0，因為必須是唯一的

Key_name?：索引的名字

Seq_in_index?：索引中該列的位置，針對聯(lián)合索引比較直觀

Column_name?：索引列的名稱

Collation?：列以什么方式存儲，可以是A或NULL，B+樹索引總是A，即排序的；如果是使用的Heap存儲引擎，并且建立了hash索引，這會顯示為NULL

Cardinality?：非常關(guān)鍵的值，標識索引中唯一值的數(shù)目的估計值，Cardinality/表的記錄數(shù)應盡可能的接近1，如果非常小,那用戶需要考慮是否還有必要創(chuàng)建這個索引。故在訪問高選擇性屬性的字段并從表中取出很少一部分數(shù)據(jù)時，對于字段添加B+樹索引是非常有必要的

Sub_part ：是否是列的部分被索引

Packed：關(guān)鍵字是否被壓縮

Null ：是否索引中含有NULL值

Index_type：索引的類型，InnoDB存儲引擎只支持B+樹索引，所以都顯示BTREE

Comment：注釋

Cardinality?值非常重要，優(yōu)化器會根據(jù)這個值來判斷是否使用這個索引，但是這個值并不是實時更新的，即并非索引的更新都會更新該值，因為代價太大，只是一個大概值

在InnoDB存儲引擎中，Cardinality統(tǒng)計信息的更新發(fā)生在兩個操作中：insert和update。InnoDB存儲引擎內(nèi)部對更新Cardinality信息的策略為:

表中1/16的數(shù)據(jù)已發(fā)生了改變

stat_modified_counter>2000 000 000

第一種策略為自從上次統(tǒng)計Cardinality信息后，表中的1/16的數(shù)據(jù)已經(jīng)發(fā)生過變化，這是需要更新Cardinality信息

第二種情況考慮的是，如果對表中某一行數(shù)據(jù)頻繁地進行更新操作，這時表中的數(shù)據(jù)實際并沒有增加，實際發(fā)生變化的還是這一行數(shù)據(jù)，則第一種更新策略就無法適用這種情況，故在InnoDB存儲引擎內(nèi)部有一個計數(shù)器start_modified_counter,

用來表示發(fā)生變化的 次數(shù),當start_modified_counter>2 000 000 000 時，則同樣更新Cardinality信息

總結(jié)

以上是生活随笔為你收集整理的mysql判断是否建立索引_判断mysql中列是否要添加索引的标准的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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