MongoDB find() 实战优化：从查不到到87毫秒的完整链路

1. 这不是语法手册，而是一份能让你当天就写出可靠查询的实战笔记

MongoDB find() 是每个刚接触文档数据库的人最先敲下的命令，但绝大多数人卡在“写出来能跑”和“写出来能用”之间——查不到数据时反复改条件却不知从何排查，聚合管道里字段名拼错三次才意识到大小写敏感，明明索引建好了查询却依然慢得像在等咖啡机煮完一壶。我带过二十多期 MongoDB 实战训练营，发现新手最常踩的坑根本不是不会写 $eq 或 $in，而是对 find() 背后执行机制缺乏基本体感：它不返回游标对象本身，而是返回一个可迭代的游标；它默认不自动展开嵌套数组，$elemMatch 不是万能钥匙；limit(1) 和 findOne() 在锁行为、索引使用、网络开销上存在本质差异。这篇笔记不讲“find() 是什么”，而是聚焦你打开 shell 后真正要面对的问题：如何在 5 分钟内定位一条订单记录，如何安全地分页查出 10 万条用户行为日志而不拖垮集群，如何让一个模糊搜索查询从 3.2 秒降到 87 毫秒。它适合刚部署完 MongoDB 的运维同学、正在调试接口的后端开发者、需要导出销售数据的运营同事——只要你需要从集合里“拿数据”，而不是“背语法”，这篇就是为你写的。核心关键词全部落在实操场景里：MongoDB find() 查询、MongoDB 模糊匹配、MongoDB 分页优化、MongoDB 索引命中验证、MongoDB 游标超时控制。

2. 整体设计思路：为什么必须抛弃“SQL 思维”来理解 find()

2.1 从关系型到文档型：一次范式迁移带来的底层逻辑重置

很多人学 find() 时下意识套用 SQL 的 WHERE 逻辑，结果越写越困惑。举个真实案例：某电商后台要查“近 7 天下单且收货地址含‘浦东新区’的用户”。SQL 写法很自然：

SELECT * FROM users WHERE created_at > '2024-04-01' AND address LIKE '%浦东新区%';

但直接翻译成 MongoDB 就会出问题：

// ❌ 错误示范：看似合理，实则隐患重重 db.users.find({ "created_at": { $gt: new Date("2024-04-01") }, "address": { $regex: "浦东新区" } })

问题在哪？三个关键点被忽略了：

第一，时间字段类型陷阱。SQL 中created_at通常是 DATETIME 类型，但 MongoDB 里它可能是字符串（"2024-04-05T10:22:33Z"）、毫秒时间戳（1712345678901）或真正的 Date 对象。如果集合里混存了字符串格式的时间，$gt比较会按字典序执行——"2024-04-01" < "2024-04-10" 成立，但 "2024-04-01" < "2024-04-2" 却为 false（因为 '2' < '1'），导致漏掉 4 月 2 日到 4 月 9 日的所有数据。我亲眼见过一个 SaaS 客户因此丢失了连续 5 天的付费转化数据，排查了两天才发现时间字段类型不统一。

第二，正则表达式性能黑洞。$regex: "浦东新区"默认启用全表扫描，即使address字段建了索引也无效。MongoDB 的文本索引（text index）才支持高效模糊匹配，但它的语法完全不同：必须用$text: { $search: "浦东新区" }，且要求查询字符串长度 ≥ 3（否则不触发索引）。更麻烦的是，text index 不支持范围查询（如$gt），所以created_at和address无法共用同一个索引——你得建两个独立索引，而查询优化器可能只选其中一个。

第三，文档结构动态性带来的路径歧义。SQL 表结构固定，address字段永远是 VARCHAR。但 MongoDB 文档里address可能是字符串，也可能是嵌套对象：

// 场景A：扁平化存储 { "address": "上海市浦东新区张江路123号" } // 场景B：结构化存储 { "address": { "province": "上海", "city": "上海", "district": "浦东新区", "street": "张江路123号" } }

用"address": { $regex: "浦东新区" }在场景 A 下能查到，在场景 B 下完全失效——因为正则匹配的是整个{...}对象的 JSON 字符串表示，而非district字段值。这时候必须用点号路径"address.district": "浦东新区"，但这就要求你提前知道数据结构，而生产环境里新老版本文档并存是常态。

所以，设计 find() 查询的第一步，不是写条件，而是做三件事：

1. 确认目标字段的真实数据类型（用db.collection.findOne().yourField查看）；
2. 检查该字段是否已建索引及索引类型（用db.collection.getIndexes()验证）；
3. 明确文档中该字段的嵌套层级（用db.collection.findOne({ yourField: { $exists: true } }, { yourField: 1 })抽样观察）。

这三步花不了 2 分钟，却能避免 80% 的“查不到”和“查太慢”问题。我坚持让所有学员在写任何 find() 前先执行这三行命令，把它变成肌肉记忆。

2.2 find() 的本质：一个懒加载的游标工厂，而非即时数据快照

很多初学者以为db.collection.find({ status: "active" })会立刻把所有活跃用户数据从磁盘读到内存，其实完全相反。find() 返回的是一个游标（cursor）对象，它只包含查询计划、索引选择、初始偏移量等元信息，真正的数据读取发生在你开始遍历它的时候。

这个特性带来两个关键影响：

影响一：游标有生命周期，超时即失效。MongoDB 默认游标空闲 10 分钟自动销毁。如果你写了一个导出脚本：

// ❌ 危险操作：游标长时间闲置 const cursor = db.orders.find({ createdAt: { $gte: startDate } }); sleep(15 * 60 * 1000); // 等待其他任务完成，15分钟后才开始处理 cursor.forEach(doc => process(doc)); // 此时游标已过期，报错 CursorNotFound

解决方案不是调大超时（noCursorTimeout: true会占用服务端资源），而是把查询拆解为小批次：

// ✅ 安全做法：分页 + 显式游标管理 let lastId = null; while (true) { const batch = db.orders.find( { createdAt: { $gte: startDate }, _id: { $gt: lastId } // 利用 ObjectId 时间有序性分页 } ).limit(1000).toArray(); // 立即执行，不保留游标 if (batch.length === 0) break; batch.forEach(process); lastId = batch[batch.length - 1]._id; }

影响二：游标支持链式方法，但顺序决定执行效率。find().sort().skip().limit()和find().limit().sort().skip()看似只是调换顺序，实际执行计划天差地别。前者先排序再截取，后者先截取再排序——如果集合有 1000 万条记录，limit(100)放在sort()前，MongoDB 只需对前 100 条排序；放在sort()后，则要对全部 1000 万条排序后再取前 100 条，CPU 和内存消耗呈指数级增长。

我做过压测：对一个 500 万文档的logs集合按timestamp排序取前 10 条，limit(10).sort({ timestamp: -1 })平均耗时 12ms；sort({ timestamp: -1 }).limit(10)平均耗时 2.8 秒。差距超过 200 倍。所以记住铁律：所有过滤（find）、排序（sort）、分页（skip/limit）操作中，limit 必须放在 sort 之后、skip 之前；而 skip 应尽可能避免，优先用基于_id或时间字段的游标分页。

2.3 方案选型：什么时候该用 find()，什么时候该换方案？

find() 是通用查询入口，但不是万能钥匙。根据我的经验，以下场景建议直接切换方案：

场景	问题	推荐替代方案	原因
需要统计总数（如count(*)）	db.collection.find(query).count()已废弃，estimatedDocumentCount()不走索引，countDocuments()全表扫描	使用aggregate([{ $match: query }, { $count: "total" }])	聚合管道中$match阶段能利用索引，$count阶段只计算匹配数，比countDocuments()快 3-5 倍
查询结果需跨集合关联（如订单+用户信息）	find()无法 join，需应用层两次查询	使用$lookup聚合阶段	减少网络往返，服务端完成关联，支持 pipeline 优化（如先$match再$lookup）
模糊搜索需高亮关键词、相关度排序	$regex无相关度，$text不支持高亮	建立 Atlas Search 索引（云服务）或用 Elasticsearch 同步	原生 MongoDB 缺乏全文搜索高级功能，硬啃只会浪费时间
需要实时监听数据变更（如订单状态更新）	find()是静态快照，无法感知后续插入	使用 Change Streams	基于 oplog 的增量监听，延迟低于 100ms，支持 resume token 断点续传

特别强调 Change Streams：它是 MongoDB 3.6+ 的核心能力，但很多团队还在用轮询find({ updatedAt: { $gt: lastCheck } })。轮询每秒 10 次，每次查询 100ms，相当于每秒向数据库发送 10 个请求；Change Streams 是长连接，一次建立永久有效，服务端主动推送变更。我们帮一家物流客户替换后，订单状态同步延迟从平均 1.2 秒降至 83 毫秒，数据库 CPU 使用率下降 37%。

3. 核心细节解析：从字段类型到索引命中的完整链路

3.1 字段类型校验：三步锁定数据真相

新手最常犯的错误，是假设字段类型和自己想的一样。MongoDB 的灵活性恰恰是最大陷阱。我整理了一套快速校验法，5 分钟内搞定：

第一步：抽样查看字段值与类型

// 查看任意一条文档中 targetField 的原始值 db.collection.findOne({}, { targetField: 1, _id: 0 }) // 查看该字段在 5 条文档中的类型分布（关键！） db.collection.aggregate([ { $sample: { size: 5 } }, { $project: { value: "$targetField", type: { $type: "$targetField" } } } ])

输出示例：

{ "value": "2024-04-01T08:00:00Z", "type": "string" } { "value": { "$date": "2024-04-01T08:00:00.000Z" }, "type": "date" } { "value": 1712345678901, "type": "long" } { "value": null, "type": "null" } { "value": [], "type": "array" }

看到type列出现多种值，立刻警觉：这个字段类型混乱，不能直接用$gt比较日期。

第二步：统计各类型文档数量（量化问题严重性）

// 统计 targetField 各类型的文档数 db.collection.aggregate([ { $group: { _id: { $type: "$targetField" }, count: { $sum: 1 } } } ])

如果string类型占 95%，date类型仅 5%，说明历史数据未规范，新写入逻辑已修复。此时查询应以字符串格式为主，但需加类型判断：

// 安全查询：兼容 string 和 date 类型 db.collection.find({ $or: [ { "targetField": { $regex: "^2024-04" } }, // 匹配字符串格式 { "targetField": { $gte: new Date("2024-04-01"), $lt: new Date("2024-05-01") } } // 匹配 Date 格式 ] })

第三步：验证索引是否覆盖该字段及类型

// 查看集合所有索引 db.collection.getIndexes() // 检查特定字段是否有索引（例如 targetField） db.collection.getIndexes().filter(i => i.key["targetField"]) // 查看查询是否命中索引（关键诊断命令） db.collection.find({ targetField: "some_value" }).explain("executionStats")

重点看executionStats中的：

• executionStages.stage: 应为IXSCAN（索引扫描），而非COLLSCAN（全表扫描）
• executionStats.totalKeysExamined: 索引键检查数，应接近executionStats.nReturned（返回数），而非远大于它
• executionStats.totalDocsExamined: 文档检查数，理想值等于nReturned

如果totalDocsExamined是nReturned的 100 倍，说明索引未生效或选择不当。常见原因：查询条件用了$ne、$not，或正则未加^锚定开头。

提示：explain()是你的 X 光机。每次写完新查询，务必执行find(...).explain("executionStats")，养成习惯。我见过太多人凭感觉调优，结果发现连索引都没建。

3.2 模糊匹配的三种武器：从简单到专业

模糊匹配是 find() 最高频需求，但不同场景必须用不同武器，乱用等于自废武功。

武器一：$regex—— 适合单次、低频、小数据量的精确模式匹配

// ✅ 合理场景：查邮箱域名（固定格式，数据量<1万） db.users.find({ email: { $regex: "@gmail\\.com$", $options: "i" } }) // ❌ 危险场景：查商品标题含“手机”（大数据量，无索引） db.products.find({ title: { $regex: "手机" } }) // 全表扫描！

$regex的致命弱点是无法利用普通索引。唯一能加速它的索引是正则索引（regex index），但 MongoDB 仅在 5.0+ 版本支持，且要求正则以^开头（锚定开头）：

// 创建正则索引（仅限 5.0+） db.products.createIndex({ title: "text" }) // text index 不适用 regex // 正确做法：创建普通索引 + 用 ^ 锚定 db.products.createIndex({ title: 1 }) // 查询必须以 ^ 开头才能用索引 db.products.find({ title: { $regex: "^iPhone" } }) // ✅ 可用索引 db.products.find({ title: { $regex: "iPhone" } }) // ❌ 全表扫描

武器二：Text Index —— 适合中等规模（<1000万）、需分词搜索的场景

// 创建 text index（对 title 和 description 字段） db.products.createIndex({ title: "text", description: "text" }) // 查询（自动分词，“智能手机”会匹配“智能”和“手机”） db.products.find({ $text: { $search: "智能手机" } }) // 排序按相关度（$textScore） db.products.find( { $text: { $search: "智能手机" } } ).sort({ score: { $meta: "textScore" } })

Text Index 的限制很明确：

• 不支持范围查询（$gt,$lt）
• 不支持正则（$regex）
• $search字符串长度 ≥ 3（否则不触发索引）
• 相关度分数是估算值，非精确匹配

所以它适合“找大概相关的内容”，不适合“找精确包含某短语的文档”。

武器三：Atlas Search（云服务）或 Elasticsearch（自建）—— 适合大规模、高精度、需高亮/同义词/拼音搜索的场景

这不是 find() 的能力范畴，而是架构选型。当你的产品需要“输入‘iphon’自动提示‘iPhone’”，或“搜索‘苹果’同时返回‘Apple’和‘水果’”，就必须跳出 MongoDB 原生能力。我们给一家跨境电商做的方案是：

• MongoDB 存业务主数据（订单、用户）
• Elasticsearch 同步商品库，用 IK 分词器 + 拼音插件构建搜索索引
• 应用层查询先走 ES 获取 ID 列表，再用find({ _id: { $in: [id1,id2,...] } })从 MongoDB 拉取详情

这样既发挥 ES 的搜索优势，又保持 MongoDB 的事务能力，查询响应稳定在 150ms 内。

3.3 分页实现：为什么 skip() 是性能毒药，以及如何无痛替换

skip(1000).limit(20)是最直观的分页写法，也是最危险的。它的原理是：MongoDB 先扫描前 1020 条文档，丢弃前 1000 条，返回后 20 条。当skip值达到 10 万，就要扫描 100020 条——无论索引多好，I/O 和 CPU 开销都线性增长。

实测数据（500 万文档orders集合，createdAt字段有索引）：

分页方式	第 1 页（skip=0）	第 500 页（skip=9980）	第 1000 页（skip=19980）
skip().limit()	12ms	186ms	372ms
基于_id的游标分页	8ms	9ms	10ms
基于createdAt的时间分页	7ms	8ms	9ms

差距在第 1000 页达到 40 倍。所以必须替换。

方案一：基于_id的游标分页（推荐，通用性强）
ObjectId 是 BSON 时间戳 + 机器码 + 进程号 + 自增计数器的组合，天然按插入时间有序。适用于所有集合：

// 第一页：取最新20条 const firstPage = db.orders.find() .sort({ _id: -1 }) .limit(20) .toArray(); // 下一页：用上一页最后一条的 _id 作为起点 const lastId = firstPage[firstPage.length - 1]._id; const nextPage = db.orders.find({ _id: { $lt: lastId } }) .sort({ _id: -1 }) .limit(20) .toArray();

方案二：基于时间字段的分页（需确保时间字段严格递增且不重复）
适用于日志、订单等时间强相关的集合：

// 第一页：最近20条 const firstPage = db.logs.find({ createdAt: { $lte: new Date() } }) .sort({ createdAt: -1 }) .limit(20) .toArray(); // 下一页：用上一页最后一条的 createdAt 作为边界 const lastTime = firstPage[firstPage.length - 1].createdAt; const nextPage = db.logs.find({ createdAt: { $lt: lastTime } // 注意：必须用 $lt，不是 $lte }) .sort({ createdAt: -1 }) .limit(20) .toArray();

注意：如果createdAt可能重复（如批量导入），$lt会导致跳过同时间的其他文档。此时应在查询条件中加入_id辅助去重：{ createdAt: { $lt: lastTime }, _id: { $lt: lastId } }。

方案三：前端维护游标（最优雅，需客户端配合）
将游标状态交给前端，服务端只负责“给下一批”：

// 请求：携带上一页的游标（base64 编码的 _id） GET /api/orders?cursor=MTIzNDU2Nzg5MHg // 服务端解码并查询 const cursorId = new ObjectId(Buffer.from(req.query.cursor, 'base64')); const results = db.orders.find({ _id: { $lt: cursorId } }) .sort({ _id: -1 }) .limit(20) .toArray(); // 响应：返回数据 + 下一页游标（最后一条的 _id） res.json({ data: results, next_cursor: results.length ? Buffer.from(results[results.length-1]._id.toString()).toString('base64') : null });

这种方案彻底规避了 skip，且支持无限滚动。我们所有新项目都强制采用此模式。

4. 实操过程：从零搭建一个可验证的查询优化工作流

4.1 环境准备：本地快速复现问题的最小闭环

不要在生产库上试错。我用 Docker 3 分钟搭一个可破坏的测试环境：

# 启动 MongoDB 6.0（带示例数据） docker run -d \ --name mongodb-test \ -p 27017:27017 \ -e MONGO_INITDB_ROOT_USERNAME=admin \ -e MONGO_INITDB_ROOT_PASSWORD=password \ mongo:6.0 # 进入容器初始化测试数据 docker exec -it mongodb-test mongosh -u admin -p password --eval " db = db.getSiblingDB('testdb'); // 创建 10 万条模拟订单 for (let i = 0; i < 100000; i++) { db.orders.insertOne({ _id: ObjectId(), userId: Math.floor(Math.random() * 10000), amount: Math.floor(Math.random() * 1000) + 10, status: ['pending', 'paid', 'shipped', 'delivered'][Math.floor(Math.random() * 4)], createdAt: new Date(Date.now() - Math.random() * 30 * 24 * 60 * 60 * 1000), tags: ['new', 'vip', 'discount'].slice(0, Math.floor(Math.random() * 3)) }); } // 创建复合索引 db.orders.createIndex({ status: 1, createdAt: -1 }); print('10w 订单数据生成完毕，索引已创建'); "

现在你可以安全地执行任何查询，explain()结果真实可信。

4.2 核心查询编写：从“能跑”到“最优”的七步法

我教团队的标准化流程，每一步都有明确产出：

步骤 1：明确业务需求（写出自然语言）

“查出所有状态为‘paid’且创建时间在最近 7 天内的订单，按创建时间倒序，取前 50 条。”

步骤 2：写出基础 find()（不考虑性能）

db.orders.find({ status: "paid", createdAt: { $gte: new Date(Date.now() - 7*24*60*60*1000) } }).sort({ createdAt: -1 }).limit(50)

步骤 3：执行 explain()，记录基线数据

db.orders.find({ ... }).sort({ ... }).limit(50).explain("executionStats")

记下executionStages.stage、totalKeysExamined、totalDocsExamined、executionTimeMillis。

步骤 4：检查索引覆盖
对照getIndexes()输出，确认status和createdAt是否在同一个复合索引中，且顺序匹配查询条件（等值查询字段在前，范围查询字段在后）。当前索引{ status: 1, createdAt: -1 }完美匹配。

步骤 5：验证索引使用效果
如果stage是IXSCAN，totalKeysExamined≈nReturned（50），说明索引生效。如果仍是COLLSCAN，检查字段名是否拼错、大小写是否一致（Status≠status）。

步骤 6：添加投影（projection），减少网络传输

// 只返回必要字段，避免传输整个文档 db.orders.find({ ... }, { _id: 1, userId: 1, amount: 1, createdAt: 1 }).sort({ ... }).limit(50)

步骤 7：压测对比（可选，但强烈推荐）
用for循环执行 100 次，取平均耗时：

function bench(query) { const start = new Date(); for (let i = 0; i < 100; i++) { db.orders.find(query).toArray(); } return (new Date() - start) / 100; } bench({ status: "paid", createdAt: { $gte: ... } }); // 基线 bench({ status: "paid", createdAt: { $gte: ..., $lt: new Date() } }); // 加 $lt 是否更快？

通过这七步，一个查询从“能跑”进化为“最优”，全程可控、可验证、可复现。

4.3 索引命中深度验证：不止看 explain，还要看 profile

explain()告诉你“这次查询怎么执行”，profile告诉你“过去 1 小时哪些查询最耗资源”。两者结合，才能发现隐藏瓶颈。

开启 profiling（生产环境谨慎，建议在测试库操作）

// 设置 profiling level 2（记录所有操作） db.setProfilingLevel(2, { slowms: 10 }) // 慢于 10ms 的都记录 // 查看最近的慢查询 db.system.profile.find({ millis: { $gt: 50 } }) .sort({ ts: -1 }) .limit(5) .pretty()

典型慢查询日志：

{ "ts": { "$date": "2024-04-05T10:22:33.456Z" }, "op": "query", "ns": "testdb.orders", "query": { "status": "pending", "amount": { "$gt": 500 } }, "millis": 1245, "nreturned": 1, "nscannedObjects": 98765, "nscanned": 98765 }

nscannedObjects（扫描文档数）远大于nreturned（返回数），说明索引未生效。此时立刻检查：

• amount字段是否有索引？
• 复合索引中amount是否在status之后？（查询条件是等值+范围，索引顺序应为{ status: 1, amount: 1 }）
• 查询是否用了$ne或$not导致索引失效？

我坚持让团队每周运行一次db.system.profile.find({ millis: { $gt: 100 } })，把结果导入 Grafana 做趋势图。连续三个月，我们把 P95 查询延迟从 1.2 秒压到 86 毫秒。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

5.1 “查不到数据”问题速查表

这是最高频问题，90% 以上源于基础疏忽。我按发生概率排序，附真实排查路径：

问题现象	可能原因	快速验证命令	解决方案
find({ name: "张三" })返回空数组	字段名拼错（Name≠name）或大小写敏感	db.collection.findOne({}, { name: 1, Name: 1, _id: 0 })	用Object.keys(doc)查看真实字段名
find({ createdAt: { $gt: "2024-04-01" } })查不到	createdAt是 Date 类型，字符串比较失败	db.collection.findOne({ createdAt: { $exists: true } }, { createdAt: 1, _id: 0 })	改用new Date("2024-04-01")
find({ tags: "vip" })查不到（tags 是数组）	数组字段需用$in或$elemMatch	db.collection.findOne({ tags: { $type: "array" } })	改用{ tags: { $in: ["vip"] } }或{ tags: { $elemMatch: { $eq: "vip" } } }
find({ status: "paid" })在大量数据中极慢	status字段无索引	db.collection.getIndexes()	db.collection.createIndex({ status: 1 })
find({})返回部分文档（非全部）	游标被其他操作中断或超时	db.collection.countDocuments({})对比db.collection.find().toArray().length	检查应用代码是否提前关闭游标，或增加noCursorTimeout: true（临时）

实操心得：遇到“查不到”，第一反应不是改查询条件，而是执行db.collection.findOne()看一条真实文档长什么样。我见过太多人对着想象中的文档结构写查询，结果字段名全是错的。

5.2 “查询太慢”问题根因分析与解决路径

慢查询不是玄学，是可定位、可优化的工程问题。我的标准排查流程：

第一步：确认是否索引问题（占慢查询的 70%）

• 执行find().explain("executionStats")，看stage是否为IXSCAN
• 如果是COLLSCAN，立即检查getIndexes()和字段类型
• 如果是IXSCAN但totalKeysExamined远大于nReturned，检查索引字段顺序是否匹配查询条件（等值字段必须在范围字段前）

第二步：确认是否数据量问题（占 20%）

• explain()中executionTimeMillis高，但totalDocsExamined接近nReturned，说明单文档处理慢
• 检查是否投影了大字段（如content: { $slice: 1000 }），或用了$where（JavaScript 执行）
• 解决方案：精简投影，避免$where，用原生操作符替代

第三步：确认是否锁竞争问题（占 10%）

• explain()中executionTimeMillis波动极大（有时 10ms，有时 2000ms）
• 查看db.currentOp()是否有长时间运行的操作阻塞
• 解决方案：优化长事务，拆分大更新，避免在高峰时段执行createIndex

真实案例：某客户报表接口 P95 延迟 3.2 秒。explain()显示IXSCAN，totalKeysExamined=nReturned= 50，但executionTimeMillis仍高。深入查currentOp()，发现一个后台任务每分钟执行db.orders.updateMany({ status: "pending" }, { $set: { updatedAt: new Date() } })，更新了 20 万文档，持有写锁。解决方案：将批量更新改为每批 1000 条，加 10ms 间隔，P95 降至 87ms。

5.3 那些文档里绝不会写的避坑技巧

这些是我在上百个项目中踩坑后总结的“反常识”技巧，没有理论包装，只有实操价值：

技巧一：永远用findOne()代替find().limit(1)做单条查询
表面看一样，但findOne()有三大优势：

• 自动设置limit: 1，服务端优化执行计划
• 返回文档对象，非游标，无需.toArray()[0]
• 在 WiredTiger 引擎下，findOne()可能跳过某些锁检查，速度提升 15-20%

// ✅ 推荐 db.users.findOne({ email: "[e-mail]" }) // ❌ 不推荐 db.users.find({ email: "[e-mail]" }).limit(1).toArray()[0]

技巧二：$in数组长度超过 100 时，拆分成多个查询
MongoDB 对$in的优化有限，当数组长度 > 100，查询计划可能退化为全表扫描。实测：$in500 个 ID，耗时 1200ms；拆成 5 个$in（每