MongoDB优化：加速id不在指定列表的文档查询及排序性能

1. 替换$not $in为$nin（等价且更简洁） #

首先明确：{id: {$not: {$in: ids}}} 和 {id: {$nin: ids}} 执行逻辑完全等价，后者写法更简洁，先统一查询写法：

const filter = {
  state: "Live",
  id: { $nin: ids },
  type: "Message",
};
const docs = await MyModel.find(filter, { _id: 0, __v: 0 })
  .sort({ "live_date": -1 })
  .lean();

2. 构建针对性复合索引（核心优化手段） #

性能慢的核心原因大概率是缺少合适的索引，导致MongoDB执行全表扫描。针对你的查询条件，创建覆盖查询+排序的复合索引：

// 通过mongoose或MongoDB Shell创建索引
MyModel.createIndex({ state: 1, type: 1, live_date: -1, id: 1 });

索引设计逻辑： #

• state:1 和 type:1 作为等值查询条件放在最前面，快速过滤出符合基础要求的文档；
• live_date:-1 按查询需要的排序方向建立，避免MongoDB在查询后执行内存排序（内存排序不仅慢，超过100MB还会触发报错）；
• id:1 包含在索引中，让MongoDB可以直接在索引层面完成$nin过滤，无需回表读取完整文档（即覆盖索引）。

创建完成后，用explain("executionStats")验证执行计划，确认stage字段为IXSCAN（索引扫描）而非COLLSCAN（全表扫描）。

3. 当ids数组极大时的进阶优化 #

如果ids数组长度超过1万甚至10万，即使有索引，$nin的过滤效率也会明显下降，此时可以换一种思路：

1. 先利用索引快速获取所有符合state: "Live", type: "Message"的文档ID和live_date；
2. 在应用层过滤掉ids中的ID；
3. 根据过滤后的ID列表查询完整文档（如果需要的字段无法通过索引完全覆盖）。

示例代码：

// 第一步：快速获取候选集（走覆盖索引，无回表开销）
const candidates = await MyModel.find(
  { state: "Live", type: "Message" },
  { id: 1, live_date: 1, _id: 0 }
).sort({ live_date: -1 }).lean();

// 第二步：应用层过滤排除目标ID
const filteredIds = candidates
  .filter(item => !ids.includes(item.id))
  .map(item => item.id);

// 第三步：查询最终文档
const docs = await MyModel.find(
  { state: "Live", type: "Message", id: { $in: filteredIds } },
  { _id: 0, __v: 0 }
).sort({ live_date: -1 }).lean();

这种方式把大量过滤逻辑从数据库转移到应用层，避免数据库处理超大数组的$nin操作，适合ids规模极大的场景。

关于“负索引” #

MongoDB没有专门的“负索引”，但通过上述复合索引设计，已经可以实现类似的高效反向过滤效果——先通过等值条件缩小数据集，再在小范围内做反向匹配，本质上和“负索引”的优化思路一致。

为什么临时集合$lookup方案更慢 #

创建临时集合、插入数据的磁盘IO和事务开销远大于直接查询，尤其是数据量较大时，整个流程的成本会远超常规查询，这种方案只适用于极特殊场景，不推荐用于常规性能优化。

内容的提问来源于stack exchange，提问作者aggaton