分片集群中索引体积更高是因为每个分片都为自身数据独立构建全量索引，非分片键索引被重复存储N次；分片键索引虽也重复存储但影响小；复合索引若盲目包含低区分度字段会加剧冗余；需直连分片验证索引实际使用效果，并手动清理各分片物理索引。
分片集群中索引体积为什么比单机高？
不是索引“变大了”，而是每个分片都独立存储一份完整索引——哪怕你只在 mongos 上执行了一次 createIndex()。MongoDB 不会把索引拆到各分片上按数据范围分布，而是让每个分片为**自己持有的那部分数据**构建全量索引结构。如果集合有 10 个分片，非分片键字段上的索引就会被重复构建 10 次，空间直接 ×10。
分片键字段索引是否也重复存储？
是的，但影响小得多。分片键字段（如 {tenant_id: 1}）本身已天然参与路由和数据划分，其 B-tree 索引节点更紧凑、深度更低；更重要的是，查询带分片键前缀时，mongos 能精准下推至目标分片，其余分片根本不参与索引扫描。但注意：只要没显式加 partialFilterExpression，该索引仍会在所有分片上完整构建，只是实际使用率低。
为什么复合索引 + 片键组合容易引发冗余？
常见错误是建了 {tenant_id: 1, status: 1, created_at: -1} 这类索引，却忽略两个事实：
– tenant_id 是分片键，它已强制出现在所有查询条件中（否则无法路由）；
– status 和 created_at 的选择性可能远低于 tenant_id，导致索引条目数爆炸式增长（尤其当 status 只有 3–5 个取值时）。
结果就是：每个分片都在为大量低区分度值维护长索引链，磁盘和内存双吃紧。
- 用
db.collection.stats()查看indexDetails中各索引的size和count，对比单分片与总集群量级 - 对高频查询，优先用
partialFilterExpression限定范围，例如{status: "active"}，让索引只覆盖活跃数据子集 - 避免在分片键后无差别追加高基数字段——先跑
db.collection.distinct("field")看取值分布，再决定是否纳入复合索引
如何验证某个索引是否真正在分片上被复用？
不能只看 getIndexes() 返回结果。必须直连具体分片节点（如 mongo --host shard1-host:27018），然后执行：db.getSiblingDB("mydb").mycoll.explain("executionStats").find({tenant_id: "t1", status: "pending"})
观察返回中的 executionStats.nReturned 与 executionStats.totalDocsExamined 是否合理（比如查 3 条却扫 1500 行，说明索引未有效过滤）。真正的复用体现在：同一索引在不同分片上，keysExamined 应随本分片数据量线性变化，而非恒定高位。
最易被忽略的一点：分片集群里没有“全局索引视图”。你以为删掉一个索引就清空了全集群，其实只是删了 mongos 元数据；各分片上的物理索引文件仍存在，直到你直连每个分片单独执行 dropIndex()。
