分片集群中不能直接用createIndex()因前台模式会阻塞活跃分片写入并拖慢复制链路；应直连各分片单独执行background:true建索引，并验证每分片索引状态与查询执行计划。
分片集群中索引创建为什么不能直接用 createIndex()？
因为默认前台模式会阻塞对应分片上的所有写入操作，而分片集群里你无法控制某个 createIndex() 请求落到哪个分片——它可能打在正扛着高流量的活跃分片上，导致局部雪崩。更糟的是，如果该分片是副本集主节点，还会拖慢整个复制链路，引发 oplog 追赶延迟、secondary 落后甚至 failover。
常见错误现象包括：writeConflict 报错频发、mongos 返回超时、监控显示某分片 queueSize 持续飙升。这不是索引本身的问题，而是创建方式没适配分片语义。
- 永远不要在业务高峰期对分片集合执行无
background: true的索引命令 - 即使加了
background: true，也要确认该选项已在所有分片节点上生效（MongoDB 4.2+ 默认强制后台，但旧版本需显式指定） - 分片键字段上建索引无需额外操作；但非分片键字段的复合索引，必须确保每个分片独立完成构建，
mongos不会帮你协调进度
如何让索引构建真正“分布式”？
所谓“分布式索引构建”，不是 MongoDB 自动并行化，而是你主动把一个大任务拆成多个小任务，在不同时间、不同分片上错峰执行。核心是绕过 mongos 的统一调度，直连各分片节点单独建索引。
实操步骤：
- 先用
sh.status()查出所有分片的host列表（例如shard1/192.168.1.103:27018） - 用
mongo --host 192.168.1.103:27018 -u admin -p pwd --authenticationDatabase admin直连第一个分片 - 在该分片上执行
db.getSiblingDB("your_db").your_collection.createIndex({field: 1}, {background: true, maxTimeMS: 7200000}) - 等该分片返回成功后，再切到下一个分片重复操作
这样做的好处是：每个分片只承担自己那份数据的索引压力，不会互相干扰；你可以给每个分片设置不同的 maxTimeMS，避免单个慢节点拖垮全局；还能配合 rs.printSecondaryReplicationInfo() 确保 secondary 已追平再操作下一分片。
为什么部分索引 + 分片键组合能大幅缩短构建时间？
如果你的查询总是带分片键前缀（比如 {tenant_id: "abc", status: "pending"}），那完全没必要对全量数据建索引。用 partialFilterExpression 限定范围，索引体积和构建耗时都会断崖式下降。
示例：
db.orders.createIndex(
{ tenant_id: 1, status: 1, created_at: -1 },
{
partialFilterExpression: { tenant_id: { $exists: true }, status: { $in: ["pending", "processing"] } },
background: true
}
)
这个索引只覆盖 tenant_id 存在且 status 是两种值之一的文档——假设只占总量 15%，那么索引大小和构建时间就大概率压缩到原来的 1/6 以内。关键点在于：partialFilterExpression 必须能被查询条件完全匹配，否则优化器不会使用它。
- 别在
partialFilterExpression里用$regex或$where，它们不支持部分索引 - 检查是否生效：用
explain("executionStats")看indexBounds和keysExamined是否明显减少 - 注意兼容性：部分索引要求 MongoDB ≥ 3.2，且不能与
unique: true同时使用
索引构建后必须验证的三件事
建完不等于可用。分片集群里最容易忽略的是索引状态同步问题——某个分片可能成功了，另一个却卡在 building 状态没报错，结果查询时部分分片走全表扫描，整体性能反而更差。
务必逐项确认：
- 用
db.getSiblingDB("your_db").your_collection.getIndexes()在每个分片上单独执行，核对索引名、字段顺序、background状态是否一致 - 查
db.currentOp({ "secs_running": { $gt: 60 }, "command.createIndexes": { $exists: true } })看是否有长时运行的建索引操作残留 - 跑一次真实查询 +
explain("queryPlanner")，确认winningPlan中的stage是IXSCAN而非COLLSCAN，且shards数组里每个分片都报告用了同一个索引名
最常被跳过的其实是最后一项：你以为索引建好了，其实只有 2/3 分片真正加载成功，剩下那个还在后台默默构建——它不报错，但也不参与查询，直到构建完成才“突然上线”，造成不可预测的性能抖动。
