索引基数低的列不宜单独建索引，因其区分度差、维护成本高且优化器常弃用；应优先联合索引、表达式索引、分区或直方图等更实效方案。
索引基数（Cardinality）低的列，强行加索引通常没用，甚至拖慢写入——关键不是“怎么算”，而是“算出来之后该不该建、怎么建、建了怎么验证”。
MySQL SHOW INDEX 里的 Cardinality 值到底靠不靠谱？
这个值是采样估算出来的，不是精确统计。InnoDB 默认只随机采样 8 个数据页（可通过 innodb_stats_sample_pages 调整），表越大、数据分布越不均，误差越明显。
- 执行
ANALYZE TABLE后才可能更新，但不保证立刻生效（受innodb_stats_auto_recalc控制） -
Cardinality显示为 1 或接近行数的 1% 以下，基本可判定区分度极低（比如性别、状态码、是否删除标记） - 别信它能反映真实查询效率——实际走不走索引，得看
EXPLAIN的key和rows字段
区分度低的列单独建 B+ 树索引几乎总是在浪费空间和写性能
B+ 树索引对低区分度列效果差，是因为优化器大概率会跳过它：等值查询时扫描的叶子节点太多，不如全表扫描；范围查询更难利用。
- 例如
status ENUM('pending','processing','done')，即使加了单列索引，WHERE status = 'pending'仍可能走全表扫描 - 每插入/更新一行，都要维护索引树，而低基数列的索引页分裂频繁、缓存命中率低
- 若该列常和其他列一起过滤，优先考虑联合索引，把高区分度列放前面（如
(user_id, status)比(status, user_id)有效得多）
真要优化低区分度列查询，试试这些更实际的手段
与其纠结基数计算，不如直接解决查询瓶颈本身。
- 用
EXPLAIN FORMAT=JSON看优化器是否真的用了索引，重点关注used_columns和range_analysis部分 - 对高频低区分度查询，考虑生成冗余字段+表达式索引（MySQL 5.7+）：
ALTER TABLE orders ADD COLUMN is_overdue BOOLEAN AS (DATEDIFF(NOW(), due_date) > 0) STORED，再给is_overdue加索引 - 分区表（RANGE/LIST）适合按低区分度列做冷热分离，比如按
status分区后，SELECT ... WHERE status = 'done'可能只需扫一个分区 - 如果只是 COUNT 统计，且允许近似值，
SELECT TABLE_ROWS FROM INFORMATION_SCHEMA.TABLES比COUNT(*)快得多（但注意它是采样估计）
基数估算偏差大时，innodb_stats_persistent 和直方图才是可控解法
默认动态采样太飘，开启持久化统计 + 手动收集直方图，能让优化器更稳地做决策。
- 设
innodb_stats_persistent = ON，再执行ANALYZE TABLE t UPDATE HISTOGRAM ON status;（MySQL 8.0+） - 直方图对低区分度列特别有用——它记录每个值的频次分布，优化器能据此判断
WHERE status = 'pending'是否值得走索引 - 注意：直方图不自动更新，数据批量变更后需手动重采；且仅影响查询优化，不改变索引结构本身
基数只是一个信号，不是判决书。真正卡住性能的，往往是没看清查询模式就堆索引，或者忽略了写放大和统计滞后这两个隐形成本。
