mongodb不支持alter index，因索引是独立结构，修改即新建+删除；需用hidden索引+应用hint实现平滑过渡，但存在分片、驱动兼容性等限制。
不能直接“优雅地在线变更索引”——MongoDB 本身不支持 ALTER INDEX 语句，所谓“平滑过渡”必须依赖隐藏索引（Hidden Indexes）+ 应用层协同，否则必然触发阻塞或重建开销。
为什么 MongoDB 没有 ALTER INDEX？
MongoDB 的索引是写时构建、读时使用的独立结构，不共享底层数据页。修改索引字段、排序方向或选项（如 unique、partialFilterExpression）本质上等于创建一个新索引 + 删除旧索引。即使使用 background: true，删除操作仍可能短暂阻塞元数据锁（尤其是在 4.2+ 中的 catalog lock），而新建索引会持续占用 I/O 和内存资源。
常见错误现象包括：
- 执行
db.collection.dropIndex("old_name")后，查询突然变慢甚至超时（旧索引已删，新索引尚未就绪） - 在副本集上，主节点完成索引重建后，从节点因同步延迟导致
index build卡住，引发IndexBuildsTimeout错误 - 应用未适配新索引字段顺序，
explain("executionStats")显示stage: COLLSCAN回退全表扫描
Hidden 索引如何实现真正平滑过渡？
Hidden 索引（MongoDB 4.4+ 支持）不会被查询优化器自动选用，但可被 hint() 强制命中，且不影响写入性能。它是灰度验证新索引效果的理想载体。
实操建议如下：
- 先用
createIndex创建带hidden: true的新索引，例如：db.orders.createIndex({ status: 1, createdAt: -1 }, { hidden: true, name: "status_createdAt_hidden" }) - 在应用中对关键查询显式
hint新索引，观察executionStats.nReturned和executionTimeMillis是否改善 - 确认稳定后，再执行
db.orders.hideIndex("status_createdAt_hidden")（注意：此操作仅移除 hidden 标记，不重建） - 最后删除旧索引：
db.orders.dropIndex("status_1")
关键点：hidden 索引的创建过程仍是后台构建，但因其不可见，不会干扰线上查询计划；而 hideIndex() 是元数据标记切换，毫秒级完成，无重建成本。
Hidden 索引的兼容性与陷阱
Hidden 索引不是万能胶——它在分片集群、特定驱动版本和聚合管道中行为受限：
- 分片集群中，hidden 索引必须在所有分片上一致存在，否则
mongos路由可能失效；需逐个分片执行createIndex并校验db.runCommand({ listIndexes: "orders" }) - PyMongo 3.12+ 和 Node.js Driver 4.15+ 才完整支持
hidden字段解析；低版本驱动可能忽略该选项，导致索引意外暴露 - 聚合管道中的
$lookup或$graphLookup不会利用 hidden 索引，即使加了hint—— 这类阶段强制走主键或默认索引 - 备份工具（如
mongodump）默认包含 hidden 索引，恢复时若目标版本低于 4.4，将报错Unrecognized field 'hidden'
比 Hidden 更轻量的替代方案：Partial Index + TTL 组合
若目标只是“渐进替换索引覆盖范围”，而非彻底重构字段组合，partial index 可避免重建开销：
- 例如原索引为
{ userId: 1 }，现需只对活跃用户加速，可建：db.users.createIndex({ userId: 1 }, { partialFilterExpression: { lastLogin: { $gt: ISODate("2026-01-01") } } }) - 再配合 TTL 索引自动清理过期文档的
createdAt字段，实际减少索引体积，间接提升查询效率 - 这种方案无需 hidden，也不需应用改 hint，只需确保查询条件能命中
partialFilterExpression
真正容易被忽略的是：hidden 索引一旦启用，就必须在所有 mongos 实例和应用配置中保持一致；哪怕一个服务实例漏掉 hint，就可能因查询计划突变引发雪崩。它解决的是“索引有效性验证”问题，而不是“原子性切换”问题。
