判断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信息