最近再看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信息
