reIndex仅在索引严重碎片时必要，盲目使用会全量锁表；推荐background重建单个索引，向量索引不支持reIndex需drop+create，特殊索引类型须先验证。
重建索引前先确认是否真有必要
重建索引（reIndex）不是日常优化手段，它只在特定场景下有效：比如集合经历了大量随机删除/更新后，索引文件出现严重碎片，explain() 显示 indexBounds 正常但 nReturned 远小于 nscannedObjects，或者 getIndexes() 中索引的 size 明显膨胀（比如比原始数据大 3 倍以上）。盲目执行 db.collection.reIndex() 会触发全量锁（FCV 4.0 下是独占写锁），阻塞所有读写——这比慢查询更伤业务。
用 reIndex 还是 dropIndex + createIndex？
两者效果不同：reIndex 是原地整理，保留索引结构和名称，但全程阻塞；而先 dropIndex 再 createIndex 可以加 {background: true} 避免锁表，但会短暂丢失索引、增加写入延迟。实际选法看场景：
- 线上核心集合且无法停写 → 用
db.collection.createIndex({...}, {background: true})重建单个索引（推荐） - 索引数量少、能接受短时停写 → 直接
db.collection.reIndex() - 发现某个旧索引已无查询使用（
serverStatus.metrics.record.moves或 Atlas Performance Advisor 显示indexCount为 0）→ 先dropIndex清理再重建必要索引
复合索引重建后顺序可能失效
重建本身不改变字段顺序，但如果你依赖 ESR（Equal, Sort, Range）原则设计的复合索引，比如 {status: 1, createdAt: -1, amount: 1}，重建后仍需验证查询是否命中索引前缀。常见坑点：
- 查询只含
{amount: {$gt: 100}}→ 不走该索引（没覆盖前缀status） - 查询
{status: "paid", amount: {$gt: 100}}→ 只能利用status前缀，amount部分无法跳过createdAt排序字段 - 用
explain("executionStats")看executionStages.stage是否为IXSCAN，且indexBounds覆盖全部查询条件
向量索引不能用 reIndex
MongoDB Vector Search 的 vectorSearch 类型索引（如 autoEmbed 字段）不支持 reIndex。它底层依赖外部 embedding 模型服务，重建必须走完整流程：
- 先
db.collection.dropIndex("vector_index_name") - 再用
createIndex重新声明，例如：db.collection.createIndex({embeddingField: "vector"}, {vectorSearchConfig: {dimensions: 1024, similarity: "cosine"}}) - 注意：重建期间所有
$vectorSearch查询失败，且 embedding 会重新生成——产生额外 token 费用和计算负载
真正容易被忽略的是：reIndex 对普通 B-tree 索引有效，但对文本、地理空间、哈希、通配符等特殊索引类型，行为未必一致；生产环境务必先在副本集 secondary 节点上验证，再操作 primary。
