n_diff_pfx是InnoDB对索引前缀列组合唯一值数量的采样估算值，非精确计数；它通过默认20页采样推算，偏差大会导致优化器误判选择性而选错执行路径。
什么是 n_diff_pfx？它不是“准确度”，而是估算值
n_diff_pfx 是 MySQL InnoDB 持久化统计信息中一个关键字段，存于 mysql.innodb_index_stats 表里，表示「某索引前缀列组合的不重复值数量估算」。比如对索引 (a, b, c)，n_diff_pfx01 对应 (a) 的基数估算，n_diff_pfx02 对应 (a,b)，n_diff_pfx03 对应完整三列。
它从来就不是精确计数——InnoDB 通过采样若干叶子页（默认 innodb_stats_persistent_sample_pages=20）来推算，本质是统计学近似。所以问题不在于“影响准确度”，而在于：这个估算偏差过大时，优化器会误判索引选择性，进而选错执行路径。
n_diff_pfx 偏差大的常见诱因
- 数据倾斜严重：比如索引首列 status 95% 是 'active'，其余 5% 分散在几十个值里。采样页若恰好没覆盖稀疏值区域，n_diff_pfx01 可能被低估为 1～2，而非真实几十
- 多列索引顺序不合理：把低基数列（如 is_deleted）放在前面，导致 n_diff_pfx01 极小，后续前缀（如 (is_deleted, created_at)）的 n_diff_pfx02 也失真
- 采样页数过少：默认 20 页对大表（千万级+）往往不够，尤其当数据按时间/ID 有序写入、分布不均时；可调高 innodb_stats_persistent_sample_pages（如设为 100）
- NULL 值处理方式不当：innodb_stats_method 设为 nulls_equal（默认）时，所有 NULL 被压进一个 bucket，若该列 NULL 占比高，n_diff_pfx 会显著偏低
如何验证和干预 n_diff_pfx 是否异常
- 查当前值：SELECT database_name, table_name, index_name, n_diff_pfx01, n_diff_pfx02, last_update FROM mysql.innodb_index_stats WHERE table_name = 'your_table';- 对比实际基数：
SELECT COUNT(DISTINCT a) FROM your_table; 和 SELECT COUNT(DISTINCT CONCAT(a, '|', b)) FROM your_table;（注意 NULL 处理）
- 手动触发重采样：ANALYZE TABLE your_table; —— 这会刷新 n_diff_pfx，但不会改变采样逻辑
- 调整采样强度（需谨慎）：ALTER TABLE your_table STATS_SAMPLE_PAGES = 100;，仅对这张表生效
为什么不能直接修 n_diff_pfx 字段？
mysql.innodb_index_stats 表虽可写，但直接 UPDATE n_diff_pfx 是危险操作：
- 优化器依赖整套统计逻辑（包括 n_leaf_pages、size 等字段协同），单改一个值易引发内部不一致
- 下次 ANALYZE 或自动更新会覆盖你的手动修改
- 若误设为远超实际的值（如把 n_diff_pfx01 改成 1e9），优化器可能错误认为该索引选择性极高，强行走索引却拖慢查询
真正可控的点只有三个：采样页数、NULL 处理策略、索引列顺序。其他都是估算结果，接受它的近似性，比试图“修正”它更稳妥。
