这篇文章主要介绍 MySQL 索引的 Cardinality 值（基数）以及索引的可选择性。

什么是索引？

先看一下 wiki 定义：

索引（英语：Index），是一本书籍的重要组成部分，它把书中的重要名词名称罗列出来，并给出它们相应的页码，方便读者快速查找该名词的定义和含义。

在 Mysql 中，索引也叫做 “键（key）”，是存储引擎用于快速找到记录的一种数据结构。这是索引的基本功能。

恰当的索引对于良好的性能非常关键。当数据量较小是，不恰当的索引对性能的影响可能不明显，但是，当数据量很大时，性能可能会急剧下降。

本小节我们就 Mysql 中索引的基数和选择性做一些讨论。

什么是索引基数（Cardinality）

先来看下索引基数的定义：

索引基数：索引基数是数据列所包含的不同值的数量。
MySQL 中，基数可以通过“show index from 表名”查看。

其会通过两个 API 来了解存储引擎的索引值的分布信息，以便决定如何使用索引。

• records_in_range() :通过向存储引擎传入两个边界值获取在这个范围内大概有多少条记录。对于 MyISAM 来说是精确值，对于 InnoDB 来说是一个估算值。
• info(): 返回各种类型的索引统计信息，其中就包括索引基数（Cardinality）（每个索引有多少条记录）。

在InnoDB存储引擎中，Cardinality 统计信息的更新发生在两个操作中：INSERT 和 UPDATE。当表中数据非常多时，不可能在每次发生 INSERT 和 UPDATE 时都去更新 Cardinality 的信息，这会增加数据库系统的负荷，同时对大表进行统计时，时间上也不允许。

因此 InnoDB 存储引擎对于更新 Cardinality 信息的策略为：表中1/16 的数据已发生变化。

与索引基数值最为密切的典型场景就是：一条 SQL 在某一时刻执行比较慢，其中较为可能的原因就是当前表记录更新频繁，这条 SQL 执行计划走的索引基数值没及时更新，优化器选择走备用索引或者走全表扫描，从而非最优执行计划，最终执行结果没有达到预期，总体查询时间较慢，这时可能得手工更新索引的基数值。

另外统计一次 Cardinality 信息所需要的时间可能非常长。这在生产环境的应用中也是不能接受的。因此，数据库对于 Cardinality 的统计都是通过采样的方法来完成的。

通过随机地读取少量的索引页面，然后以此为样本，计算索引的统计信息，默认采样页数是 8。InnoDB 可以通参数 innodb_stats_sample_pags 来设置样本也的数量。设置更大的值，理论上来说可以帮助生成更准确的索引信息。特别是对于索引页记录数较少时。

什么是索引选择性？

索引选择性 = 索引基数/数据总数。

索引的可选择性好与坏，和索引基数关系非常密切。基数值越高，索引的可选择性越好；相反，基数越低，索引的可选择性越差。优化器优先使用的索引一般选择性都不差，除非没得选，才会走选择性稍差点的索引或者走全表扫描。

MYSQL 如何使用索引？

之所周知，MYSQL 优化器使用的是基于成本的模型。而衡量成本的主要指标就是一个查询需要扫描多少行。如果表没有索引统计信息，或者索引统计信息不准确，优化器就很有可能做出错误的决定。

统计信息不准确的问题可以通过 ANALYZE TABLE 来重新生成统计信息解决。

如果存储引擎向优化器提供的扫描行数信息是不准确的数据，或者执行计划本身太复杂以致无法准确的获取各个阶段匹配的行数，那么优化器就会使用索引统计信息来估算扫描行数。

下面来举例说明索引基数在不同的数据分布场景下的变化以及对优化器的影响。

案例分析

数据准备

存储过程：

delimiter //
# 删除表数据
DROP TABLE IF EXISTS `cardinality_sample`;
# 创建表
CREATE TABLE `cardinality_sample` (`id` int NOT NULL AUTO_INCREMENT,`r1` int DEFAULT NULL,`r2` int DEFAULT NULL,`r3` int DEFAULT NULL,`r4` int DEFAULT NULL,`r5` tinyint DEFAULT NULL,`r6` date DEFAULT NULL,PRIMARY KEY (`id`),KEY `idx_u1` (`r1`,`r2`,`r3`),KEY `idx_r4` (`r4`),KEY `idx_r5` (`r5`),KEY `idx_r6` (`r6`)
) ENGINE=InnoDB ;drop procedure IF EXISTS batchInsert; 
create procedure batchInsert()
begindeclare num int; set num=1;while num<=100 doINSERT INTO `cardinality_sample` (`r1`, `r2`, `r3`, `r4`, `r5`, `r6`) VALUES ( MOD(num,29), MOD(num,91),MOD(num,97),MOD(num,20),MOD(num,10),date_add(NOW(), interval num day));set num=num+1;end while;
end
//
delimiter; #恢复;表示结束

执行上述存储过程： CALL batchInsert;

数据如下：

查看索引基数

# 查询索引基数
show index from cardinality_sample

从以上结果可以看出，主键基数最高，极限接近于表记录数；联合索引 idx_u1 次之；索引 idx_r6 值为 86，也不差；比较差的为 idx_r4、idx_r5，分别为 20、10，其中 idx_r5 最差，仅仅为表记录数的 1/10。索引 idx_r5 类似于我们常说的状态类索引，由于所以基数很低，优化器一般不选择这个索引，一般不需要加，加了反而影响表的写性能。

其中，联合索引 idx_u1 的基数是按照多个键值依次组合计算，分别为(r1),(r1,r2),(r1,r2,r3)

select 'r1', count(distinct r1) idx_u1 from cardinality_sample
union all
select 'r1,r2', count(distinct r1,r2) idx_u1 from cardinality_sample
union all
select 'r1,r2,r3', count(distinct r1,r2,r3) idx_u1 from cardinality_sample;

现在有一个 sql;

select * from cardinality_sample where  r4 = 2 and r5 = 2;

select * from cardinality_sample where r4 = 2 ; 有 5 条记录返回
select * from cardinality_sample where r5 = 2 ; 有 10 条记录返回

问，要想这个 sql 语句的查询效率，需要 给 r4 和 r5 建立联合索引吗，如果需要的话，r4 在前？还是 r5 在前？

ALTER TABLE `test`.`cardinality_sample` 
ADD INDEX `idx_u45`(`r4`, `r5`) USING BTREE,
ADD INDEX `idx_u54`(`r5`, `r4`) USING BTREE;

EXPLAIN select * from cardinality_sample where r4=30 and r5 = 30

如果是

EXPLAIN select count(*) from cardinality_sample where r4=2 and r5 = 2

再看两条基于字段 r6 的 SQL 语句：

SQL1: select * from cardinality_sample where r6 between '2022-11-28' and '2023-03-12'
SQL2: select count(*) from cardinality_sample where r6 between '2022-11-28' and '2023-03-12'

上面 SQL 2、SQL 3 两条 SQL 的过滤条件一样，都是一个范围。不同的是 SQL 2 打印符合过滤条件的记录，而 SQL 3 是打印符号过滤条件的记录条数。单从过滤条件来看，这两条 SQL 的执行计划应该一样，那分别看下两条 SQL 的执行计划：

EXPLAIN select * from cardinality_sample where r6 between '2022-11-28' and '2023-03-12'

EXPLAIN select count(*) from cardinality_sample where r6 between '2022-11-28' and '2023-03-12'

从执行计划看，SQL1 没走索引，走全表扫描；而 SQL2 直接走索引取回记录数，避免了访问表数据。那为什么两条 SQL 的过滤条件一样，执行计划却不一样呢？

SQL 2 顺序全表扫描表数据的速度要比走索引再随机扫描表数据快很多，因为要打印的记录数有 100 条,表记录总数也有 100 条。索引 idx_r6 的基数其实很高了，但是由于最终返回的记录数太多，MySQL 只能放弃走索引；而 SQL2 由于只求符合过滤条件的记录数，直接从索引入口就可以计算出来结果。

那如果把 SQL1 的过滤条件收缩下，再次查看执行计划：

EXPLAIN select * from cardinality_sample where r6 between '2022-11-28' and '2022-11-31';

从执行计划看，直接走了索引。

那之前的 SQL 2 过滤条件要是不变化，能否会用到索引呢？这个就与索引的基数值以及索引基于一定过滤条件的选择性好坏有很大的关系。比如由于某些业务变化，表 cardinality_sample 字段 r6 的数据分布发生了变化（表行数变大，字段 r6 对应范围的数据收窄）。由于数据分布发生变化，索引基数值也发生了改变，基于同样过滤条件的索引选择性也从差变好，可能就会走到索引。

假如我们的数据经过一段时间变化，索引基数如下：

再次用相同的查询语句，查看执行计划：

EXPLAIN select * from cardinality_sample where r6 between '2022-11-28' and '2023-03-12'

索引 idx_r6 的基数由之前的 100 提升到 32w 多。所以即使同样的字段，同样的过滤条件，不同的索引基数值以及基于索引基数值的索引选择性高低的不同，也会让优化器选择不同的执行计划。