MySQL 直方图之外如何判断列选择性是否真实下降

MySQL 里的“列选择性下降”不能只看直方图 JSON 是否变了。更可靠的判断是：先用当前数据算出列的实际分布，再用同一个过滤条件对照优化器估算行数和真实行数，最后检查索引基数与统计信息更新时间。这样才能分清是数据真的变得更集中，还是统计信息过期导致执行计划误判。

先把“选择性下降”拆成数据和执行计划

工程上常把不同概念都叫“选择性”。如果关心一列能否把候选行缩小，可以先看不同值占比；如果关心某条 SQL，则应该看谓词命中率。对同一张表，status 有很多不同值，不代表 status = 'active' 一定只命中少量行。

本文把“下降”定义为过滤能力变弱：同一个业务谓词命中的行占比变大，或者优化器估算与真实行数的偏差变大。先固定表、列、谓词和时间窗口，再比较两次采样，避免把查询条件变化误认为数据分布变化。

用真实样本计算过滤比例，不只看直方图

下面的查询只用于建立排查基线。COUNT(DISTINCT) 不把 NULL 当作一个普通不同值，因此同时保留非空总数；目标谓词则直接计算命中行数。示例中的列名需要替换成你的业务列。

-- 统计列的不同值占比，并单独记录 NULL，避免口径混在一起
SELECT
  COUNT(*) AS total_rows,
  COUNT(customer_region) AS non_null_rows,
  COUNT(DISTINCT customer_region) AS distinct_values,
  COUNT(DISTINCT customer_region) / NULLIF(COUNT(customer_region), 0) AS distinct_ratio,
  SUM(customer_region = '华东') AS matched_rows,
  SUM(customer_region = '华东') / NULLIF(COUNT(*), 0) AS predicate_ratio
FROM orders;

-- 用固定时间窗口复查，避免新增历史数据改变比较基线
SELECT
  COUNT(*) AS window_rows,
  SUM(customer_region = '华东') AS matched_rows,
  SUM(customer_region = '华东') / NULLIF(COUNT(*), 0) AS window_ratio
FROM orders
WHERE created_at >= '2026-09-01'
  AND created_at 

如果 predicate_ratio 从 0.08 变成 0.31，说明这个谓词实际要处理的行更多，过滤能力确实变弱。但这不自动意味着索引失效：还要看索引顺序、回表成本、连接顺序和优化器估算是否同步变化。

用 EXPLAIN ANALYZE 对照估算与实际行数

先看计划，再用可接受的测试流量运行一次 EXPLAIN ANALYZE。重点不是只看 cost，而是比较节点里的 rows= 与 actual ... rows=。估算接近实际但返回行数本来就很多，问题偏向数据分布或索引收益不足；估算很小而实际很多，优先怀疑统计信息或谓词相关性。

-- 先观察优化器选择的访问路径，不执行查询
EXPLAIN FORMAT=TREE
SELECT order_id, created_at
FROM orders
WHERE customer_region = '华东'
  AND created_at >= '2026-09-01';

-- 只在可控环境运行；该语句会真实执行 SELECT 并给出 actual 行数
EXPLAIN ANALYZE
SELECT order_id, created_at
FROM orders
WHERE customer_region = '华东'
  AND created_at >= '2026-09-01';

例如计划估算 rows=1200，实际节点显示 actual ... rows=18500，先记录误差比，不要立即强制索引。若刷新统计后估算仍偏离，再检查多列相关性、范围条件和数据倾斜；若估算与实际都显示大量命中，则应重新评估复合索引的列顺序或查询是否需要更窄的业务条件。

把索引基数和统计信息时间放进决策表

对有索引的列，MySQL 可以通过索引统计或 index dive 估算等值条件；直方图更常用于非索引列或无法从索引分布得到好估算的场景。先查看索引基数和统计时间，再决定动作：

-- CARDINALITY 是索引分布的估算值，先保存排查前的结果
SHOW INDEX FROM orders;

-- 只刷新指定表的键分布；完成后要重新执行同一 EXPLAIN 对照
ANALYZE TABLE orders;

-- 需要直方图时再查看更新时间和采样信息，不把 JSON 变化当作结论
SELECT SCHEMA_NAME, TABLE_NAME, COLUMN_NAME, HISTOGRAM
FROM INFORMATION_SCHEMA.COLUMN_STATISTICS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'orders'
  AND COLUMN_NAME = 'customer_region';

最后保留刷新前后的计划、实际行数和业务查询耗时。若只是统计信息问题，刷新后估算应更贴近现实；若数据本身已经高度倾斜，统计信息只能帮助 MySQL“看清”现状，不能让低选择性的谓词凭空变高。

常见问题

选择性比例越大越好吗？

要先说明口径。不同值占比大通常表示更分散，但具体谓词的命中率越大，过滤能力通常越弱；文章中的“下降”采用后者。

刷新直方图后计划没有变化怎么办？

这是正常可能性。优化器可能优先使用范围估算或索引 dive，或者真实命中行数本来就很多，应回到 EXPLAIN ANALYZE 和索引列顺序继续判断。

能用 CARDINALITY 直接算出准确不同值数吗？

不能。它是索引统计估算，不等同于精确的 COUNT(DISTINCT)；需要精确口径时应在可接受成本下对业务时间窗口单独统计。