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

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

table?索引所在表名

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

Key_name?：索引的名字

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

Column_name?：索引列的名稱

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

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

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

Packed：關鍵字是否被壓縮

Null ：是否索引中含有NULL值

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

Comment：注釋

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

在InnoDB存儲引擎中，Cardinality統計信息的更新發生在兩個操作中：insert和update。InnoDB存儲引擎內部對更新Cardinality信息的策略為:

表中1/16的數據已發生了改變

stat_modified_counter>2000 000 000

第一種策略為自從上次統計Cardinality信息后，表中的1/16的數據已經發生過變化，這是需要更新Cardinality信息

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。