起因与问题
使用MySQL做数据，有时会隐约感觉到一些语句执行速度极其慢，而理论上应该是很快的。通常使用phpMyAdmin作为客户端，在表结构页里可以方便的看到索引状态，对基数cardinalyty一知半解，隐约理解为惟一值个数。
但前两天写一条查询语句执行速度非常非常慢，看到一个索引的基数竟然是空的，而且明明应该有很多值。猜测MySQL出bug了，于是删除并重建了索引，基数正常了，语句也飞快跑完。于是稍多留意了一下索引基数。同一天，看到一个基数为1的索引，也是很多惟一值的字段，这也不正常。因为是MyISAM表，直接打包了对应的.frm, .MYD, MYI 三个文件，保留一个现场，有时间再做研究。
回顾了问题表生成语句，整理出一个简单化的重现过程，下面讨论。
问题重现
测试平台为 MySQL 5.5, MariaDB 10.3，其它版本应该也是类似。直接上语句
/* ************************************************* */
-- 一张数据表，并填充一些数据，稍微大一些
DROP TABLE IF EXISTS `d_src` ;
CREATE TABLE `d_src` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`org` char(32) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `org` (`org`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 ;
INSERT INTO `d_src`(org) VALUES (md5('abcdefg'));
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
INSERT INTO `d_src`(org) SELECT md5(concat(org,id,rand()*id)) FROM `d_src`;
-- 新建一张表，这里先使用 MyISAM 存储引擎，用来重现问题。插入数据，加字段及索引，UPDATE
DROP TABLE IF EXISTS `d_making`;
CREATE TABLE `d_making` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`org` varchar(50) NOT NULL DEFAULT '',
`cnt` int(10) unsigned NOT NULL DEFAULT 0,
PRIMARY KEY (`id`),
KEY `org` (`org`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
insert into `d_making`(`org`)
SELECT `org` FROM `d_src`
ORDER BY id desc;
ALTER TABLE `d_making` ADD org_fix varchar(50) NOT NULL DEFAULT '', ADD INDEX (org_fix);
UPDATE `d_making` SET org_fix=left(org,2 );
-- watch the index status, the Cardinality of Key org_fix is 1
SHOW index FROM d_making;
此时查看索引状态，注意org_fix索引的基数，竟然是1 ! 删除并重建索引，再看
-- rebuild index and show key again, the Cardinality NOT 1 ALTER TABLE `d_making` DROP INDEX `org_fix`, ADD INDEX `org_fix` (`org_fix`); SHOW index FROM d_making;
org_fix的基数应该是256左右（因为是原始数据是随机数，大概在256的附近）。
按上脚本，只d_making表改用InnoDB存储引擎，结果也类似，也许不是1，但也明显不对。
不过，在MySQL 8.0 (CentOS 8默认配置)下，得到了 258，比真实值256要大。
原因探求
最早注意到索引基数时，搜索过相关资料，但仍是一知半解。这次通过 “mysql cardinality rebuild index” 查询，找到stackoverflow上有类似问题，最终找到mysql官方手册的一段说明：
Cardinality
An estimate of the number of unique values in the index. To update this number, run ANALYZE TABLE or (for MyISAM tables) myisamchk -a.
Cardinality is counted based on statistics stored as integers, so the value is not necessarily exact even for small tables. The higher the cardinality, the greater the chance that MySQL uses the index when doing joins.
理解下来，说是索引基数只是个估算值，并不一定可靠，可以用 ANALYZE TABLE 表 更新。事实上，删除并重建索引并不一定奏效。SQL语句执行时，优化器会依据索引基数决定是否使用索引，于是，基数不正确（过小）的索引，就不能被选用，于是这个索引事实上无效了。
结论
- MySQL索引基数，可能不准确（过大过小都有可能），从而可能造成语句执行时忽略该索引（索引失效）。
- 要想让该值准确，得在表数据有改动后跑一遍 ANALYZE TABLE table_name
对使用者来说，这是个潜在的坑。手工运行SQL语句前，可以事先关注一下索引基数是否正常（或先 explain一下）。如果是在线生产环境，可能就要自求多福了，或者搞一大群的计划任务，跑ANALYZE TABLE. 不过，理论上，没有大面积UPDATE的字段的索引，这个问题不大。
后记
再深入一点，索引基数即是MySQL统计信息，关系型数据库的查询优化器要依据统计信息确定是否使用某个索引；而统计信息并非实时更新的。本问题的即是统计信息未及时更新的一个极端案例。也就是说，这个问题并非MySQL本身的缺陷，应该在关系型数据库中普遍存在。