MongoDB作为文档型数据库，在JS全栈项目中常被用作主存储。当数据量增长到几十万甚至上百万条时，查询变慢几乎都和索引有关。理解索引的内部运作方式，才能有针对性地进行优化，而不是盲目添加索引。
MongoDB索引的底层原理与常见类型
MongoDB默认使用B树（更准确说是B+树变体）来构建索引。当我们对一个字段建立索引时，数据库会额外维护一棵有序树，树叶子节点保存了索引字段的值以及对应文档的物理位置或_id。执行查询时，如果查询条件能命中索引，MongoDB就从树根向下查找，时间复杂度约为O(log n)，远小于全表扫描的O(n)。如果未命中索引，就会执行COLLSCAN，逐条读取集合中的文档进行匹配。
单字段索引是最基础的形式，适用于只按某一个字段查询的场景，例如按用户ID查订单。复合索引则针对多个字段的组合查询，字段顺序非常关键，遵循最左前缀原则。假设建立{ a: 1, b: 1 }的复合索引，那么查询条件包含a，或同时包含a和b都能命中；但如果只查b，则无法使用该索引。还有一种特殊的是覆盖索引，即查询所需的所有字段都包含在索引中，此时MongoDB无需回表取文档，速度极快。
除了普通索引，MongoDB还支持唯一索引、文本索引、地理空间索引等。在JS全栈应用里，最常碰到的性能问题来自复合索引设计不当和缺失覆盖索引。举个例子，一个商品集合常有按分类和创建时间筛选并排序的需求，如果只建了分类的单字段索引，排序仍可能触发内存排序导致变慢。合理建立{ category: 1, createdAt: -1 }复合索引，既能加速过滤也能优化排序。
JS全栈中服务端查询代码的索引优化实践
在Node.js服务端，我们通常使用官方驱动mongodb或ORM如Mongoose。优化第一步是确保在集合上创建合适的索引。可以在应用启动时调用createIndex，但要注意生产环境应避免阻塞式建索引，推荐使用后台建索引或Atlas的在线索引构建。下面是一段Node.js中创建复合索引并捕获错误的示例：
const { MongoClient } = require('mongodb');
async function initIndexes() {
const client = new MongoClient('mongodb://127.0.0.1:27017');
await client.connect();
const db = client.db('shop');
const coll = db.collection('products');
try {
// 建立分类与时间的复合索引，支持筛选与排序
await coll.createIndex({ category: 1, createdAt: -1 }, { background: true });
console.log('索引创建成功');
} catch (err) {
console.error('索引创建失败', err);
} finally {
await client.close();
}
}
initIndexes();
第二步是利用explain方法分析查询是否真正走了索引。很多开发者凭感觉加索引，结果查询计划里仍是COLLSCAN。在代码中可以执行coll.find(query).explain('executionStats')，查看winningPlan里的stage字段。如果是IXSCAN说明命中索引，如果是COLLSCAN就要调整索引或查询。同时关注totalKeysExamined与totalDocsExamined，两者越接近说明索引过滤越精准。
另一个常见陷阱是前端的模糊搜索直接拼正则。比如用{ name: /手机/ }做前缀正则时，若name有索引还能命中，但中缀正则/.*手机.*/则完全无法使用索引。在JS全栈中，这类请求经接口传到服务端后，应在Node层做校验，对模糊搜索引导使用文本索引而非随意正则，否则数据库CPU会被拖垮。
全栈视角下的查询性能综合治理
索引优化不能只盯数据库。在JS全栈架构里，一次查询延迟可能是前端重复请求、Node服务串行等待、或缺少缓存叠加导致的。比如列表页在组件挂载时发请求，子组件又各自查同一数据，造成倍数级压力。服务端可用Redis缓存热门查询结果，将MongoDB索引优化后的毫秒级查询再降到微秒级响应，但缓存键要包含查询参数以防脏数据。
分页也是重灾区。传统的skip(largeNumber).limit(n)在深分页时，即便有索引，也要先扫描跳过大量记录。更好的做法是游标分页，用上一页最后一条的排序字段值作为条件，例如{ createdAt: { $lt: lastTime } }配合索引{ createdAt: -1 }，这样每次查询都能精准走索引范围扫描。在Node接口层改写分页逻辑，前端传lastId而非pageNum，整体性能会显著提升。
最后要建立监控习惯。MongoDB的慢查询日志、Atlas的Performance Advisor都能指出缺失索引。在CI流程中接入查询计划检查，防止新接口写出全表扫描代码。只有把索引原理、服务端写法与全栈请求链路结合起来，才能稳妥地解决MongoDB在JS项目中的查询性能瓶颈。