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

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

踩过这个坑,还有下一个坑等着你,这一路就是给自己填坑,坑填多了,也就习惯了,直到这一路平坦了,也就无怨无悔了。
原文地址:https://www.cnblogs.com/xiaofeilin/p/13964921.html