planCacheClear不能修复索引统计不准问题，它仅清除查询计划缓存，而MongoDB的索引基数统计由WiredTiger后台采样自动更新，不可手动触发，且受采样比例固定、稀疏字段易漏样、无事务级快照等硬限制影响。
planCacheClear 不能修复索引统计不准问题，它清的是查询计划缓存，不是统计信息本身。 索引基数（CARDINALITY）不准在 MongoDB 里是另一套机制，和 MySQL 的 ANALYZE TABLE 不同——MongoDB 没有直接更新统计信息的命令，它的采样统计由后台自动触发或写入时隐式更新，无法手动“重算”。
为什么 planCacheClear 看起来“有用”但实际治标不治本
执行 db.collection.planCacheClear() 后查询变快，往往是因为旧的错误执行计划（比如选了低效索引、走了 IXSCAN + FETCH 而非 COUNT_SCAN）被清掉了，优化器被迫重新生成计划。但它下次仍可能基于过时的统计再次选错——尤其当数据分布突变（如某字段突然大量新增 $exists: true 值）而采样未覆盖时。
- 统计信息更新依赖
backgroundThread或写操作触发，不保证实时，也不暴露控制接口 -
planCacheClear不影响keysExamined/docsExamined偏高这类底层问题，只换了个计划而已 - 在分片集群中，各 shard 统计独立更新，
planCacheClear只清当前 mongos 连接的缓存，不跨节点同步
真正影响统计准确性的三个硬限制
MongoDB 的统计采样逻辑藏在存储引擎层（WiredTiger），你无法绕过这些限制：
-
internalQueryCacheMaxEntries默认 1000：计划缓存条目上限，满后按 LRU 清除，但不会主动淘汰“过期统计依赖的计划” - 采样页数固定：WiredTiger 对每个索引按固定比例采样（非可配参数），对稀疏字段（如
producttags仅 0.2% 存在）极易漏掉有效值 - 无事务级统计快照：长事务期间，
count()或explain()可能读到 MVCC 版本链里的旧统计值，表现为CARDINALITY长期卡在低位
遇到统计不准时该做什么（而非 planCacheClear）
优先验证是否真由统计导致，再针对性干预：
- 用
db.collection.explain("executionStats").count({...})查nReturnedvsdocsExamined比值，若远小于 1（如 3/1498），说明索引筛选率差，大概率是统计偏差或索引设计缺陷 - 检查字段稀疏性：
db.collection.aggregate([{$group:{_id:null, total:{$sum:1}, hasTags:{$sum:{$cond:[{"$gt":[{"$strLenCP":"$producttags"},0]},1,0]}}}}])，确认$exists是否真稀疏 - 改用部分索引：
db.collection.createIndex({"deliverytime":1}, {partialFilterExpression: {"producttags": {"$exists": true}}})，让索引只覆盖有效子集，绕过采样失真 - 对高频
count()场景，用 TTL 集合+定时聚合预存结果，避免每次走实时统计
统计不准的本质是 WiredTiger 的采样不可控，planCacheClear 只是抖了个机灵。真正要稳，得从索引结构（部分索引）、查询模式（避免稀疏字段主导排序）、甚至数据写入节奏（减少突增）上动手——别指望一个缓存清理命令解决底层采样缺陷。
