当前位置：首页 > news >正文

MongoDB博客数据建模实战：嵌入、引用与混合策略

news 2026/7/6 10:57:14

1. 为什么博客应用的数据建模不能照搬关系型数据库那一套？

刚接手一个技术博客平台重构项目时，我第一反应是画ER图、分用户表、文章表、标签表、评论表——结果两周后在MongoDB里跑出一堆$lookup聚合慢得像卡顿的旧手机。后来翻遍官方文档和十几个真实上线项目的源码才明白：MongoDB不是“能存JSON的MySQL”，它是一套完全不同的数据思维操作系统。核心关键词就三个：嵌入（Embedding）、引用（Referencing）、混合建模（Hybrid Modeling），而博客场景恰恰是这三者博弈最典型的战场。这篇文章不讲抽象理论，只说我在三个不同体量博客（日活500人小站、日均万级PV中型社区、百万级内容平台）里踩坑、验证、最终沉淀下来的建模逻辑。它解决的是具体问题：为什么你加个“点赞数”字段总要双写更新？为什么按标签查文章越来越慢？为什么评论数统计总不准？适合谁看？如果你正在用MongoDB做博客类应用，或者正纠结该选关系型还是文档型数据库，又或者已经上线但发现查询变慢、扩展吃力——这篇就是为你写的实操手册，所有方案都经过生产环境验证，参数、结构、代码片段全部可直接抄作业。

2. 博客核心实体拆解与建模策略选择逻辑

2.1 博客四大核心实体的本质差异

博客系统表面看只有“文章、用户、评论、标签”四个词，但每个实体在数据生命周期、读写频率、一致性要求上天差地别。建模的第一步，不是急着设计字段，而是给每个实体贴上三张标签：读多写少 / 写多读少 / 读写均衡、强一致性要求 / 最终一致性可接受、是否频繁关联查询。我拿自己维护的中型技术博客（月活30万）的真实数据说话：

文章（Post）：读多写少（99%请求是读）、强一致性（发布即可见）、极少单独按文章ID以外的条件深度关联（比如不会“查某用户所有被点赞过的文章”这种跨维度聚合）。
用户（User）：读写相对均衡（注册/登录/资料修改）、强一致性（密码、邮箱不能错）、几乎不参与高频聚合（用户列表页不常刷）。
评论（Comment）：写多读少（发评是动作，查看是被动）、最终一致性可接受（延迟几秒再显示新评论不影响体验）、必须按文章ID快速拉取（每篇文章下最多展示前20条）。
标签（Tag）：读多写少（标签创建极少）、强一致性（标签名不能重复）、高频关联（查“Java”标签下的所有文章，且需分页）。

提示：这个分类不是拍脑袋定的。我用MongoDB的db.currentOp()和db.setProfilingLevel(2)抓了三天线上慢查询，87%的耗时集中在“按标签查文章列表”和“拉取某文章全部评论”两个场景。建模必须围绕这些真实瓶颈展开。

2.2 嵌入、引用、混合：没有银弹，只有权衡

MongoDB官方文档把嵌入和引用说得像非此即彼的选择题，但真实项目里90%的成功案例都是混合使用。关键在于识别数据的“粘性”和“流动性”：

嵌入（Embedding）适用场景：数据天然属于某个父文档、几乎不独立存在、体积小、更新频率低。比如文章的基础元数据（标题、摘要、封面图URL、发布时间）——它们和文章ID绑定，删文章就删掉，改标题不涉及其他表。
引用（Referencing）适用场景：数据需要被多个父文档共享、体积大、更新频繁、或需独立查询。比如用户头像URL——同一个用户可能在100篇文章的作者字段里出现，但头像只存一份；又比如评论内容——单条评论可能被点赞、被回复，独立存在价值高。
混合建模（Hybrid）真实形态：文章文档里嵌入作者基本信息（用户名、头像缩略图），但引用用户ID；评论文档里嵌入评论者昵称和头像（避免每次查评论都要join用户表），但引用用户ID用于权限校验；标签则完全独立成集合，用数组字段tags: ["mongodb", "nosql"]存于文章中，实现快速过滤。

注意：很多人误以为“嵌入=性能好”，其实不然。我试过把100条评论全嵌入文章文档，单文档大小冲到16MB上限，find()操作内存暴涨，备份时mongodump直接OOM。MongoDB单文档16MB硬限制是铁律，嵌入前必须算体积：一条纯文本评论平均200字，UTF-8编码约200字节，100条就是20KB，安全；但若嵌入带HTML格式、图片base64的评论，一条就超1MB，5条就爆。

2.3 为什么拒绝“一刀切”的规范化思维？

关系型数据库里，我们本能地把“作者信息”抽成users表，因为范式要求消除冗余。但在MongoDB里，冗余不是原罪，网络往返才是真凶。举个真实例子：首页文章列表要显示每篇文章的作者头像、用户名、粉丝数。如果严格引用，一次拉10篇文章就要发起10次db.users.findOne({ _id: authorId })查询——即使加了索引，10次网络RTT（假设平均20ms）就是200ms，用户感知就是卡顿。而嵌入作者基础信息后，10篇文章一次find()搞定，实测首屏加载从1.2s降到380ms。代价是什么？作者改头像时，要批量更新所有ta写过的文章文档里的头像字段。但数据表明：一个活跃作者平均每月只改1.3次头像，而首页日均被访问2.4万次。用一次低频写操作，换数万次高频读的性能飞跃，这笔账怎么算都划算。这就是MongoDB建模的核心哲学：为读优化，为写妥协。

3. 四大核心集合的详细结构设计与参数推演

3.1 文章集合（posts）：主干结构与关键字段设计

文章是博客的绝对核心，它的结构决定了整个系统的扩展性。我摒弃了早期用author: { name: "...", avatar: "..." }这种深嵌套对象的设计，改用扁平化+关键字段冗余。当前生产环境使用的结构如下（已脱敏）：

{ "_id": ObjectId("65a1b2c3d4e5f67890123456"), "slug": "mongodb-data-modeling-guide", "title": "MongoDB Data Modeling Guide for Blogging Apps", "content": "<p>...完整HTML内容...</p>", "excerpt": "本文详解博客应用在MongoDB中的建模实践...", "coverImage": "https://cdn.example.com/covers/mongodb-guide.jpg", "status": "published", // draft, published, archived "publishAt": ISODate("2024-01-15T08:00:00Z"), "createdAt": ISODate("2024-01-10T14:22:33Z"), "updatedAt": ISODate("2024-01-15T08:00:00Z"), "author": { "id": ObjectId("5f1a2b3c4d5e6f7890123456"), "name": "张工", "avatar": "https://cdn.example.com/avatars/zhanggong.jpg", "bio": "十年数据库老兵" }, "tags": ["mongodb", "data-modeling", "blog"], "categories": ["database", "backend"], "stats": { "views": 1247, "likes": 89, "commentsCount": 23, "shares": 17 }, "seo": { "metaTitle": "MongoDB建模指南 | 技术博客", "metaDescription": "手把手教你为博客应用设计高性能MongoDB数据模型..." } }

关键设计解析：

slug字段独立存储：这是SEO刚需，避免每次从title生成（中文title转拼音有歧义），且作为URL路径唯一标识，建唯一索引{ slug: 1 }。
content存完整HTML：不拆分段落或富文本JSON，因为博客正文极少按段落查询，反而是全文检索（MongoDB Atlas Search）更常用。体积控制靠CDN压缩和前端懒加载。
author子文档只存强读需求字段：name、avatar、bio（作者简介）——首页列表、文章详情页顶部都需立即显示。id字段保留用于后台权限校验（如“只允许作者编辑自己的文章”）。
stats子文档内聚统计：views用$inc原子操作更新，likes和commentsCount同理。绝不在应用层读-改-写，那是并发冲突的温床。
tags和categories用字符串数组：支持{ tags: "mongodb" }高效查询，且MongoDB对数组字段的索引优化极好（{ tags: 1 }索引可支撑$in、$all等操作）。

实操心得：stats.likes初始值设为0而非null，避免应用层空值判断。我见过团队因likes: null导致前端点赞按钮状态错乱，排查两天才发现是建模时没约定默认值。

3.2 用户集合（users）：安全与扩展性的平衡点

用户集合看似简单，但安全字段（密码哈希、重置令牌）和扩展字段（社交账号、订阅偏好）的处理稍有不慎就会埋雷。我们的结构兼顾安全合规与未来扩展：

{ "_id": ObjectId("5f1a2b3c4d5e6f7890123456"), "email": "zhanggong@example.com", "passwordHash": "$2b$12$abc123...", "emailVerified": true, "status": "active", // active, inactive, banned "profile": { "name": "张工", "avatar": "https://cdn.example.com/avatars/zhanggong.jpg", "bio": "十年数据库老兵", "location": "上海", "website": "https://zhanggong.dev" }, "auth": { "lastLoginAt": ISODate("2024-01-15T10:22:11Z"), "failedLoginAttempts": 0, "lockedUntil": null }, "preferences": { "theme": "dark", "newsletter": true, "commentNotifications": true }, "social": { "github": "zhanggong", "twitter": "zhanggong_dev" } }

关键设计解析：

email建唯一索引{ email: 1 }，且小写标准化存储（应用层统一email.toLowerCase()），避免ZhangGong@ExAmple.com和zhanggong@example.com被当成两个用户。
passwordHash绝不存明文，用bcrypt（ $2b$ 前缀）且cost=12——这是安全与性能的黄金平衡点。cost=10太弱，cost=14在高并发登录时CPU飙升。
profile子文档收纳所有公开信息，auth子文档专注认证状态，preferences和social按业务域隔离。这种分组不是为了好看，而是为未来API权限控制打基础：/api/user/profile只返回profile字段，/api/user/auth需管理员权限才能访问。
failedLoginAttempts和lockedUntil实现防暴力破解：连续5次失败后锁定30分钟。MongoDB的$inc和$set可原子完成，无需应用层锁。

注意：social.github这类字段不建索引。理由很实在——除了用户自己看，几乎没人会查“GitHub用户名为zhanggong的所有用户”。索引是磁盘空间和写性能的消耗者，只为高频查询字段建。

3.3 评论集合（comments）：高并发写入的结构化解法

评论是博客里写压力最大的模块。新评论提交、点赞、回复都会触发写操作，且要求强实时性（用户发完立刻看到）。我们放弃“嵌入到文章里”的诱惑，坚持独立集合，但通过结构设计压降延迟：

{ "_id": ObjectId("65a1b2c3d4e5f67890123457"), "postId": ObjectId("65a1b2c3d4e5f67890123456"), "author": { "id": ObjectId("5f1a2b3c4d5e6f7890123457"), "name": "李同学", "avatar": "https://cdn.example.com/avatars/lixue.jpg" }, "content": "受益匪浅！有个小疑问：嵌入评论和引用评论的性能临界点怎么算？", "status": "approved", // pending, approved, rejected, spam "createdAt": ISODate("2024-01-15T11:30:22Z"), "updatedAt": ISODate("2024-01-15T11:30:22Z"), "likes": 5, "repliesCount": 2, "parentCommentId": null, // 用于构建树形结构 "isTopLevel": true // 根评论为true，回复为false }

关键设计解析：

postId建索引{ postId: 1, createdAt: -1 }：这是评论列表页的生命线。按文章ID升序+时间倒序，确保db.comments.find({ postId: xxx }).sort({ createdAt: -1 }).limit(20)毫秒级响应。实测1000万条评论下，该查询稳定在15ms内。
status字段实现内容审核：pending状态评论不显示，后台审核通过后$set: { status: "approved" }，避免删除再插入引发ID变更。
parentCommentId和isTopLevel支撑无限级回复：根评论parentCommentId=null且isTopLevel=true；回复的parentCommentId指向被回复评论ID，isTopLevel=false。前端用两次查询组装树：先查{ postId: xxx, isTopLevel: true }，再查{ parentCommentId: { $in: [id1, id2, ...] } }。比单次递归查询更可控。
likes和repliesCount用原子操作更新，repliesCount在新增回复时$inc，删除回复时$inc: -1，避免读-改-写。

踩过的坑：早期用replies: [{...}, {...}]嵌入回复，结果热门文章下回复超200条，单文档膨胀，备份失败。现在独立集合+索引，写入吞吐量提升3倍，且支持按“最多赞回复”排序（{ postId: xxx, status: "approved" }.sort({ likes: -1 })）。

3.4 标签集合（tags）：从字符串数组到可运营实体的跃迁

很多团队把标签当作文档里的一个普通数组字段，直到要做“标签热度榜”或“标签关注数”时才发现无法下手。我们的做法是：让标签成为一等公民，独立集合存储，并与文章双向关联：

{ "_id": ObjectId("65a1b2c3d4e5f67890123458"), "name": "mongodb", "slug": "mongodb", "description": "关于MongoDB数据库的一切", "postCount": 47, "followerCount": 1280, "createdAt": ISODate("2023-05-20T09:15:00Z"), "updatedAt": ISODate("2024-01-15T08:00:00Z") }

关联逻辑：

文章文档中仍保留tags: ["mongodb", "data-modeling"]数组，用于快速过滤。
同时，标签集合中postCount字段记录该标签下文章总数。每当文章发布/下架，用$inc原子更新对应标签的postCount。
用户关注标签时，向用户文档的followingTags: [ObjectId("...")]数组$push，并$inc标签的followerCount。

为什么值得多这一套？

运营价值：后台可直接查db.tags.find().sort({ postCount: -1 }).limit(10)生成“热门标签榜”，或sort({ followerCount: -1 })生成“最受关注标签”。
数据一致性：postCount由数据库原子操作保证，永不出现“文章写了标签，但标签计数没加”的情况。
查询效率：查“mongodb标签下所有文章”仍是db.posts.find({ tags: "mongodb" })，毫秒级；而“查关注了mongodb标签的所有用户”则是db.users.find({ followingTags: ObjectId("...") })，同样高效。

提示：slug字段对标签同样重要。name: "MongoDB"和name: "mongodb"应视为同一标签，入库前统一小写+去空格，slug作为唯一标识建唯一索引。

4. 索引策略、聚合管道与性能调优实战

4.1 索引不是越多越好：精准打击高频查询

MongoDB索引是B-tree结构，每个索引占用磁盘空间并拖慢写入速度。我们的原则是：只为P95以上耗时查询建索引，且优先复合索引。基于真实慢查询日志，我们为四大集合配置了以下核心索引：

集合	索引定义	支持的典型查询	说明
`posts`	`{ status: 1, publishAt: -1 }`	`find({ status: "published" }).sort({ publishAt: -1 })`（首页列表）	覆盖状态过滤+时间排序，避免内存排序
`posts`	`{ tags: 1, publishAt: -1 }`	`find({ tags: "mongodb" }).sort({ publishAt: -1 })`（标签页）	数组字段索引天然支持`$in`、`$all`
`posts`	`{ slug: 1 }`	`find({ slug: "xxx" })`（文章详情页）	唯一索引，极速定位
`comments`	`{ postId: 1, createdAt: -1 }`	`find({ postId: xxx }).sort({ createdAt: -1 })`（评论列表）	如前所述，生命线索引
`comments`	`{ author.id: 1, status: 1, createdAt: -1 }`	`find({ "author.id": xxx, status: "approved" }).sort({ createdAt: -1 })`（用户个人评论页）	支持作者视角的评论管理
`tags`	`{ slug: 1 }`	`find({ slug: "mongodb" })`	唯一索引，保障标签唯一性

关键避坑点：

绝不为单字段_id建索引：MongoDB自动为_id创建唯一索引，手动建是浪费。
慎用text索引：全文检索需求用MongoDB Atlas Search（云服务）或Elasticsearch替代，text索引在大数据量下性能不可控。
索引字段顺序决定生死：{ status: 1, publishAt: -1 }能支撑status过滤+publishAt排序，但{ publishAt: -1, status: 1 }就不能——因为B-tree先按publishAt排序，status是乱序的，MongoDB仍需内存过滤。

实操技巧：用db.posts.explain("executionStats").find({ status: "published" }).sort({ publishAt: -1 })查看执行计划。重点关注executionStats.totalDocsExamined（扫描文档数）和executionStats.executionTimeMillis（执行毫秒数）。理想状态是totalDocsExamined等于返回文档数，且executionTimeMillis < 10。

4.2 聚合管道（Aggregation Pipeline）：复杂查询的终极武器

当简单find无法满足需求时，聚合管道是救星。但滥用$lookup（类似JOIN）会导致性能雪崩。我们的经验是：能用索引解决的，绝不用聚合；必须用聚合的，把$lookup放到最后。以下是三个高频场景的实战管道：

场景1：首页文章列表 + 每篇文章的作者粉丝数（需关联users集合）

db.posts.aggregate([ { $match: { status: "published" } }, { $sort: { publishAt: -1 } }, { $limit: 10 }, { $lookup: { from: "users", localField: "author.id", foreignField: "_id", as: "authorInfo" } }, { $unwind: "$authorInfo" }, { $project: { _id: 1, title: 1, excerpt: 1, "author.name": "$authorInfo.profile.name", "author.avatar": "$authorInfo.profile.avatar", "author.followerCount": "$authorInfo.stats.followerCount", // users集合中需有此字段 publishAt: 1 } } ])

为什么这样写？先$match+$sort+$limit把数据量压到10条，再$lookup——只查10次users集合，而非全量文章都查。实测100万文章下，此管道耗时稳定在45ms；若把$lookup放前面，耗时飙升至2.3秒。

场景2：标签页 + 分页 + 总数（避免countDocuments二次查询）

db.posts.aggregate([ { $match: { tags: "mongodb" } }, { $facet: { "data": [ { $sort: { publishAt: -1 } }, { $skip: 0 }, // 第一页，跳过0条 { $limit: 10 } ], "totalCount": [ { $count: "count" } ] } } ])

$facet在一个管道里同时计算数据和总数，避免应用层先countDocuments再find的两次往返。返回结果是{ data: [...], totalCount: [{ count: 47 }] }，前端直接取totalCount[0].count。

场景3：文章详情页 + 关联的最新3条评论（非全部）

db.posts.aggregate([ { $match: { slug: "mongodb-data-modeling-guide" } }, { $lookup: { from: "comments", localField: "_id", foreignField: "postId", as: "comments", pipeline: [ { $match: { status: "approved" } }, { $sort: { createdAt: -1 } }, { $limit: 3 } ] } } ])

pipeline选项在$lookup内部执行，只拉取3条评论，而非全量再$slice，网络传输量直降90%。

注意：聚合管道调试用$explain，但$explain不显示$lookup内部管道的执行细节。我的习惯是分段测试：先单独运行$lookup内部的db.comments.find(...).sort(...).limit(3)，确认其性能达标，再整合进主管道。

4.3 写入性能调优：从原子操作到批量处理

博客应用的写操作虽不如读多，但评论、点赞、阅读统计的并发量不容小觑。我们通过三层优化保障写入稳定：

第一层：原子操作替代读-改-写

错误示范：

// 应用层读取文章 const post = await db.posts.findOne({ _id: postId }); // 计算新阅读数 const newViews = post.stats.views + 1; // 再写入 await db.posts.updateOne({ _id: postId }, { $set: { "stats.views": newViews } });

问题：并发时，两个请求读到相同的views=100，都算101，最终写入101而非102。

正确做法（原子操作）：

await db.posts.updateOne( { _id: postId }, { $inc: { "stats.views": 1 } } // 数据库层面原子自增 );

第二层：批量写入降低网络开销

用户一次性给10篇文章点赞，不要发10次updateOne。用bulkWrite：

const operations = postIdList.map(postId => ({ updateOne: { filter: { _id: postId }, update: { $inc: { "stats.likes": 1 } } } })); await db.posts.bulkWrite(operations);

第三层：异步化非核心写入

阅读统计（views）和分享数（shares）对实时性要求不高。我们用消息队列（如RabbitMQ）解耦：前端只记录“用户A在时间T看了文章B”，消费端异步聚合更新stats.views。好处是：1）首页列表查询不受写入影响；2）可做UV去重（同一用户24小时内多次访问只计1次）；3）扛住突发流量（如文章被大V转发，瞬间10万访问）。

实操心得：$inc操作对NumberInt32和NumberLong类型最友好。我们所有统计字段（views,likes,commentsCount）都显式声明为NumberLong，避免JavaScript数字精度丢失（超过2^53后整数不精确）。

5. 常见问题排查与独家避坑指南

5.1 “查询越来越慢”问题的根因定位四步法

当同事喊“MongoDB变慢了”，我绝不先看索引，而是按此流程排查：

第一步：确认是读还是写慢？
用db.currentOp({ secs_running: { $gt: 5 } })查当前运行超5秒的操作。若返回大量update或insert，问题在写入；若多为find或aggregate，聚焦读取。

第二步：定位慢查询语句
开启慢查询日志：db.setProfilingLevel(1, { slowms: 100 })（记录>100ms操作）。然后查db.system.profile.find().sort({ ts: -1 }).limit(5)，复制最慢的query字段，在Studio 3T或mongosh里explain。

第三步：检查索引覆盖度
对慢查询explain，看executionStats.executionStages.stage是否为IXSCAN（走索引）或COLLSCAN（全表扫描）。若为COLLSCAN，且nReturned远小于totalDocsExamined，说明缺索引。

第四步：验证索引有效性
新建索引后，用db.collection.getIndexes()确认存在，再用db.collection.stats()看size和count是否合理增长。曾遇过索引建错字段名（{ statu: 1 }少了个s），getIndexes显示存在，但实际无效。

独家技巧：在开发环境用mongostat --host localhost:27017实时监控。重点关注qrw（queued reads/writes）列，若持续>0，说明查询积压，急需优化。

5.2 “数据不一致”问题的高频场景与修复

场景1：嵌入的作者信息未同步更新
现象：用户改了头像，但旧文章里还是老图。
根因：应用层只更新了users集合，忘了$set所有相关文章的author.avatar。
修复方案：

短期：用db.posts.updateMany({ "author.id": userId }, { $set: { "author.avatar": newAvatar } })批量修复。
长期：在用户资料更新API里，增加此批量更新逻辑，或用Change Streams监听users集合变更，自动触发文章更新。

场景2：评论数统计（commentsCount）与实际评论数不符
现象：文章显示23条评论，但拉取评论只有20条。
根因：commentsCount用$inc更新，但删除评论时忘了$inc: -1，或status为pending的评论被计入但未显示。
修复方案：

短期：用聚合管道校准——db.comments.countDocuments({ postId: xxx, status: "approved" })得到真实数，再$set到文章。
长期：删除评论时，强制$inc: { "stats.commentsCount": -1 }，且status字段必须有默认值（"pending"），杜绝null状态。

场景3：标签文章数（postCount）虚高
现象：标签mongodb显示47篇文章，但db.posts.countDocuments({ tags: "mongodb" })只有45条。
根因：文章下架（status改为archived）时，只改了文章状态，没减标签计数。
修复方案：

短期：写脚本遍历所有标签，用db.posts.countDocuments({ tags: tag.slug, status: "published" })重新计算postCount。
长期：文章状态变更时，用事务（MongoDB 4.0+）保证“更新文章状态”和“更新标签计数”原子性。

注意：事务不是银弹。我们只在“文章发布”这种强一致性场景用事务，日常更新不用——事务有性能开销，且需副本集部署。

5.3 “磁盘空间暴涨”问题的诊断与清理

MongoDB磁盘用满是线上事故高发区。常见原因及对策：

WiredTiger缓存未释放：WiredTiger引擎会缓存数据，db.serverStatus().mem显示resident内存高，但磁盘未涨。重启mongod可释放，但非长久之计。对策：调整storage.wiredTiger.engineConfig.cacheSizeGB（建议设为物理内存的50%-60%），避免缓存挤占磁盘空间。
Oplog过大：副本集的oplog是固定大小集合，用于主从同步。默认占磁盘5%。若写入量大，oplog可能撑满。查大小：db.getReplicationInfo()。对策：增大oplog，rs.replSetResizeOplog(10240)（单位MB，此处设10GB）。
未清理的旧备份：mongodump生成的备份文件堆积。对策：用find /backup -name "*.gz" -mtime +7 -delete定期清理7天前备份。
TTL索引失效：为logs或sessions集合建了TTL索引（{ expiresAt: 1 }），但expiresAt字段未正确设置。查失效文档：db.sessions.find({ expiresAt: { $lt: new Date() } }).count()。对策：确保插入时expiresAt: new Date(Date.now() + 3600000)（1小时后过期）。

实操心得：用db.collection.stats()看size（集合大小）、storageSize（磁盘占用）、nindexes（索引数）。若storageSize远大于size，说明索引过多或文档碎片严重，考虑db.collection.reIndex()（注意：会阻塞写入）。

5.4 从开发到上线：环境差异导致的“本地快、线上慢”问题

本地开发用MacBook，线上用4核8G云服务器，同样的查询线上慢3倍。这不是玄学，是可定位的：

硬件差异：本地SSD，线上可能是HDD或网络存储。用iostat -x 1看%util（设备利用率），若持续>80%，IO是瓶颈。
连接池配置：Node.js的mongodb驱动默认连接池大小是5。线上高并发时连接不够，请求排队。对策：new MongoClient(uri, { maxPoolSize: 100 })。
网络延迟：本地localhost无延迟，线上应用与MongoDB可能跨可用区。用ping和mtr测网络。对策：将应用与MongoDB部署在同一可用区，或用MongoDB Atlas的专用网络连接。
查询计划缓存（Query Plan Cache）：MongoDB会缓存查询计划。本地数据少，选了COLLSCAN；线上数据多，缓存的计划仍是COLLSCAN，导致慢。对策：db.runCommand({ clearQueryCache: "posts" })清空特定集合缓存，让数据库重新生成计划。