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資訊

 

　　
 

https://www.cnblogs.com/manmanrenshenglu/p/12036620.html