mysql判断是否建立索引_判断mysql中列是否要添加索引的标准

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