如果直接在聚合管道中写一个$createIndexes阶段，MongoDB会直接报错：Unrecognized pipeline stage name: '$createIndexes'。这个报错说明索引创建并不是聚合管道的一部分。聚合管道的作用是处理集合中的文档数据，例如过滤、投影、分组、排序、连接和写入等，所有这些阶段操作的都是文档流，而不是集合的元数据或索引结构。索引的创建和管理属于数据库管理命令的范畴，需要在集合级执行。
从设计上看，聚合管道保持无副作用的读取和转换语义，唯一可能修改数据库状态的阶段是$out和$merge，它们将结果写入集合。如果允许$createIndexes作为管道阶段，会让管道承担两类截然不同的职责：数据转换与结构管理。这种混合不仅会破坏管道可组合性，还容易出现重复建索引或错误建索引的问题。因此MongoDB没有提供这样的阶段，所有索引操作都应通过createIndexes命令、db.collection.createIndex()或管理工具完成。
有些开发者会把创建索引的命令名和聚合阶段命名混淆，因为两者都使用美元符号开头。实际上MongoDB命令和聚合阶段虽然在文档中都以类似JSON的形式出现，但执行环境不同。数据库命令通过db.runCommand发送，聚合阶段只能出现在aggregate()方法的pipeline数组中。
db.orders.aggregate([
{ $match: { status: "active" } },
{ $createIndexes: { key: { userId: 1 }, name: "idx_userId" } }
])
执行上述代码后，MongoDB不会创建任何索引，而是返回错误提示，因为$createIndexes不是合法的管道阶段。理解这一点是正确设计数据应用的基础。
一、为什么聚合管道中不存在$createIndexes阶段
聚合管道本质上是一个文档处理流水线，输入是集合中的一批文档，输出是转换后的文档流。管道中的每个阶段接收文档、处理文档、再传递文档。比如$match负责过滤，$project负责字段裁剪，$group负责分组聚合，$sort负责排序。这些阶段从来不会修改集合本身的物理结构。
索引是一种特殊的存储结构，用来加速查询和排序。创建索引需要扫描集合数据、排序键值、构建B-tree或其他索引结构，这个操作会直接改变集合的磁盘布局和写入性能。如果把索引创建混入聚合管道，那么管道执行到某一步时，上游文档流还在传输，下游要重新组织整个集合的存储结构，这在执行模型上是冲突的。MongoDB的设计原则是让聚合管道专注于数据流转换，让管理命令专注于元数据操作，这样才能保证管道可预测、可复用。
因此，即使你看到一些教程或代码片段里尝试在管道中写$createIndexes，它们要么是笔误，要么是把数据库命令和管道阶段搞混了。正确的做法是在聚合管道之外，单独执行创建索引的命令。
二、MongoDB中创建索引的正确方式
MongoDB提供了多种创建索引的方式。最常用的驱动层方法是db.collection.createIndex()，它接收一个包含字段名和排序方向的文档，例如{ userId: 1 }表示在userId字段上创建升序索引，{ createdAt: -1 }表示在createdAt字段上创建降序索引。如果需要同时创建多个索引，可以使用db.collection.createIndexes()。
// 创建单字段索引
db.orders.createIndex({ userId: 1 })
// 创建复合索引
db.orders.createIndex({ status: 1, createdAt: -1 })
// 使用createIndexes一次创建多个索引
db.orders.createIndexes([
{ key: { userId: 1 }, name: "idx_userId" },
{ key: { status: 1, createdAt: -1 }, name: "idx_status_created" }
])
除了基础字段索引，MongoDB还支持多种索引选项。唯一索引可以在字段上保证值不重复，稀疏索引跳过缺失字段的文档，TTL索引可以自动过期文档，部分索引只对符合过滤条件的文档建索引，隐藏索引则可以让查询优化器暂时忽略某个索引。例如，要为邮箱字段创建唯一索引并跳过缺失值，可以这样写：
db.users.createIndex(
{ email: 1 },
{ unique: true, sparse: true, name: "idx_email_unique_sparse" }
)
底层数据库命令同样可以完成这些操作。createIndexes命令的格式如下：
db.runCommand({
createIndexes: "orders",
indexes: [
{ key: { userId: 1 }, name: "idx_userId", unique: true }
]
})
无论使用哪种方式，索引创建都应该在集合存在且数据写入策略明确后进行。创建索引会消耗CPU和I/O资源，并且可能阻塞写入，因此需要根据业务低峰期安排执行。
三、聚合管道结果集合的索引策略
聚合管道虽然不能直接创建索引，但经常会把结果写入新的集合。比如使用$out阶段将聚合结果保存到一个新集合，或者使用$merge把结果合并到已有集合。此时目标集合的索引需要单独规划。如果目标集合是新创建的，它默认只有_id索引，查询性能可能很差。
db.transactions.aggregate([
{ $match: { status: "completed" } },
{ $group: { _id: "$userId", total: { $sum: "$amount" } } },
{ $out: "user_totals" }
])
// 写入完成后，再为输出集合创建业务需要的索引
db.user_totals.createIndex({ total: -1 })
db.user_totals.createIndex({ _id: 1, total: -1 })
这里的关键问题是建索引的时机。如果目标集合已经存在索引，并且$merge在持续写入数据，那么每次插入或更新文档时，MongoDB都要同步维护这些索引，这会明显降低写入吞吐量。因此在大量数据导入或聚合输出前，可以考虑先删除非必要索引，等数据写入完成后再重新创建。如果必须保持索引在线，则要评估写入延迟和查询性能之间的平衡。
对于一次性生成的报告集合，更推荐先执行聚合写入，再创建索引。这样写入阶段不受索引维护的影响，创建索引时数据库可以一次性全量构建索引，效率更高。对于需要频繁合并更新的目标集合，则要谨慎选择索引数量和字段，避免维护成本超过查询收益。
四、聚合管道如何利用已有索引加速
虽然管道本身不能创建索引，但聚合查询可以从已有索引中获益。最典型的情况是管道第一个阶段为$match，如果$match中的过滤条件用到了为查询服务的前缀索引，MongoDB查询优化器就能使用该索引快速定位文档，而不是全表扫描。
db.orders.createIndex({ userId: 1, createdAt: -1 })
db.orders.aggregate([
{ $match: { userId: 12345 } },
{ $sort: { createdAt: -1 } },
{ $limit: 20 }
])
上面的复合索引{ userId: 1, createdAt: -1 }可以同时满足$match对userId的过滤和$sort对createdAt的排序，聚合管道执行时能显著减少扫描的文档数。如果管道中的$match没有被索引覆盖，就需要扫描整个集合，性能会急剧下降。
$lookup阶段同样依赖索引。当聚合管道连接外部集合时，外部集合的连接字段如果没有索引，每次查找都可能退化为全集合扫描，导致连接成本呈指数级增长。例如，订单聚合需要关联客户信息，应该给客户集合的customerId字段建索引：
db.customers.createIndex({ customerId: 1 })
db.orders.aggregate([
{ $lookup: {
from: "customers",
localField: "customerId",
foreignField: "customerId",
as: "customerInfo"
}}
])
对于$group和$project这类阶段，普通索引的直接加速效果有限，但可以通过在管道开头先使用$match减少进入后续阶段的文档数量，间接提升整体性能。因此，良好的聚合性能依赖合理的集合索引设计，而不是指望管道内部能创建索引。
总结来说，$createIndexes并不是聚合管道阶段，创建索引必须通过独立的命令或驱动方法完成。理解这一点，并针对源集合和输出集合分别设计索引策略，才能让MongoDB聚合任务既正确又高效地运行。
MongoDB聚合管道createIndexes索引创建修改时间：2026-08-20 04:45:51