索引选择性
索引选择性是索引基数(cardinality)与表中数据行数(n_row_in_table)的比值,即
索引选择性=索引基数/数据行
其中cardinality是索引中不重复记录的预估值。
不是所有的查询条件出现的列都需要添加索引。对于什么时候添加B+树索引。一般的经验是,在访问表中很少一部分时使用B+树索引才有意义。对于性别字段、地区字段、类型字段,他们可取值范围很小,称为低选择性。如
SELECT * FROM student WHERE sex='M'
按性别进行查询时,可取值一般只有M、F。因此SQL语句得到的结果可能是该表50%的数据(加入男女比例1:1)这时添加B+树索引是完全没有必要的。相反,如果某个字段的取值范围很广,几乎没有重复,属于高选择性。则此时使用B+树的索引是最合适的。例如对于用户名字段,基本上在一个应用中不允许重名的出现。
通过SHOW INDEX结果可以看到列Cardinality。Cardinality非常关键,表示索引中不重复记录的预估值。需要注意的是Cardinality是一个预估值,而不是一个准确值。基本上用户也不可能得到一个准确的值。在实际应用中,索引选择性应尽可能的接近1,如果非常小,那用户需要考虑是否还有必要创建这个索引。故在访问高选择性属性的字段并从表中取出很少一部分数据时,对于字段添加B+树索引是非常有必要的。
cardinality是怎么预估的?
上面提到cardinality是索引中不重复记录的预估值,那么它是怎么实现的呢?由于Mysql的B+索引在每个存储引擎中实现的都不一样,所以cardinality干脆放到存储引擎层面实现的!
对于innodb来说,达到以下2点就会重新计算cardinality
- 如果表中1/16的数据发生变化
- 如果stat_modified_counter>200 000 0000
这是为什么呢?因为真实环境中,索引的更新可能非常频繁,比如一个表中数据的插入,更新,删除等,每次都去统计cardinality会带来很大的负担;另外如果是一个大表,统计一次可能非常耗时。基于此,采用基于上面2个条件的"抽样"统计的方式。
那上面2种有什么区别呢?
- 如果表中1/16数据发生变化则会更新;
- 第2种情况比较特别,如果某一千数据频繁更新,但是数据并没有增加,则第一种无法适用,所以设置stat_modified_counter为发生变化的次数;如果次数达到200 000 0000,也会更新统计值。
那具体是如何采样统计的呢?
- 获取B+树叶子节点的数据,记为A
- 随机获得B+树索引中8个叶子节点。统计每个页不同记录的个数,分别记为P1,P2...P8
- 计算cardinality = (P1+P2+...P8)A/8从而得出索引中不同记录的数量。
从上面可以发现,有2个问题
- 由于是随机采样的方式,所以会出现,连续2次统计,数量都不同。只有在表数据非常少,叶子节点不多于8个时,每次采样都是取到相同的页,统计值才会相同。
- 由于统计值是基于上面2个条件去更新的,可能出现系统运行了一段时间之后,数据发生了很大变化,统计值偏差比较大了,那么索引的效率会下降。
那对于问题2,该怎么处理呢?
手动更新统计值
如果系统运行一段时间之后,我们可以通过执行下面的sql,重新计算cardinality值
analyze table tb_name; show table status; show index from tb_name
不过,如果表很大,重新统计可能会非常耗时间,建议对于核心表,在非高峰时段操作。
总结
- cardinality代表的是此列中存储的唯一值的个数,如果此列为primary key 则值为记录的行数,如果是复合索引就是唯一组合的个数。
- cardinality只是个估计值,并不准确。
- cardinality将会作为mysql优化器对语句执行计划进行判定时依据。如果唯一性太小,那么优化器会认为,这个索引对语句没有太大帮助,而不使用索引。
- cardinality值越大,就意味着,使用索引能排除越多的数据,执行也更为高效。
- cardinality不会自动更新,需要通过analyze table来进行更新。
- cardinality的大小影响join时是否选用这个index的判断。
- 初建index时,MyISAM的表cardinality的值为null,InnoDB的表cardinality的值大概为行数。
- MyISAM与InnoDB对于cardinality的计算方式不同