芙蓉塘外有轻雷直接说结论：MongoDB是我在生产环境里用得最久、也踩坑最多的NoSQL数据库，没有之一。这玩意儿表面上看起来就是"存JSON的数据库"，好像随便装一个就能跑，但真到了数据量上来、查询变慢、复制集脑裂、分片key选错的那一天，你就会发现它骨子里的性格和关系型数据库完全不一样。这篇不是官方文档的复读，是拿实际项目经验来讲MongoDB的核心特性到底怎么用、能解决什么问题、在什么场景下千万别硬上。
先说说这篇文章适合谁看：正在做技术选型、纠结到底上不上MongoDB的后端开发；已经装了MongoDB但只是当"更好用的MySQL"在用的工程师；以及被慢查询、索引失效、磁盘暴涨折磨的运维同学。如果你只是写个Demo、本地存点数据，那随便玩，但如果你要把它放到生产环境里扛真实流量，这篇里的每一个坑你都躲不开。
1. 为什么是MongoDB：它到底解决了什么问题
1.1 从关系型数据库的痛点说起
我在做传统业务系统的那几年，每天跟MySQL打交道，感受最深的一点是：关系型数据库的表结构一旦定下来，后面每次业务变动都像在旧地基上盖新楼。加一个字段要ALTER TABLE，改一个状态枚举要写迁移脚本，多对多关系要拆关联表，查询稍微复杂点就得上JOIN。数据量上了千万级以后，一个三表JOIN能把数据库CPU打到90%以上，加索引、调SQL、分库分表，运维和开发累死累活。
不是MySQL不好，而是它设计的初衷是保证数据一致性和关系完整性，这本身就是有代价的。很多互联网业务场景，比如商品详情、用户画像、文章内容、设备上报数据，它们的数据结构天然就是"一坨完整的JSON"，你非要把它拆成十几个表，再在查询的时候拼回去，这纯属自己给自己找麻烦。
再说一个更痛的点：关系型数据库的扩展方式基本就是垂直扩展，单库单表顶不住就上分布式中间件，中间件会引入分库分表规则、分布式事务、跨库JOIN等问题。水平扩展不是做不到，但成本和复杂度非常高，而且通常要改业务代码去做路由。
1.2 MongoDB的定位与设计哲学
MongoDB的设计哲学非常直接：数据是怎么用的，就怎么存。它的核心存储单元是文档（Document），一个文档就是一个完整的、自包含的数据对象，对应到业务上往往就是一个完整的业务实体。比如一个订单，在MongoDB里就是一条文档，里面有用户信息、商品列表、收货地址、支付记录、物流信息，全都在这一条里。
这种设计给开发带来的第一个红利就是"没有映射成本"。后端拿到的请求体是JSON，存进MongoDB的也是BSON（二进制JSON），读出来再返回给前端还是JSON，中间不需要做任何ORM映射。你少写的那堆Model、Mapper、转换器，省下来的不只是代码量，还有大量因为字段对应错误产生的Bug。
第二个设计哲学是"默认分布式"。MongoDB从设计之初就把复制集（Replica Set）和分片（Sharding）作为一等公民，而不是后加的补丁。复制集提供高可用，分片提供水平扩展，它们和数据库内核深度集成，不是外挂的中间件。这一点和传统关系型数据库对比特别明显：MySQL的主从复制和分库分表方案，到今天都还需要大量外围工具和人工介入。
再补一个很多人忽略的点：MongoDB的Schema-less并不是"不需要设计Schema"，而是"Schema的演进成本极低"。你可以随时给文档加字段，不用改表结构，这在业务快速迭代的阶段简直是救命稻草。但注意，这是双刃剑，后面建模章节我会详细讲。
1.3 适合与不适合的场景边界
先说适合的场景，我总结成四类：
- 内容管理类：文章、资讯、商品详情、配置信息。这类数据天然是嵌套结构，读多写少，不需要复杂事务。
- 用户画像与行为日志：用户属性、标签、行为序列，结构变化频繁，字段不固定。
- 物联网设备数据：设备上报的JSON数据，字段随设备型号不同而变化，写入量大。
- 快速迭代的互联网业务：产品需求三天一小变五天一大变，数据库结构能跟上业务变化才是王道。
再说不适合的场景，这个更重要，因为很多人栽在这里：
- 强事务一致性业务：比如金融账务、库存扣减，需要多文档原子性操作和复杂ACID事务。MongoDB从4.0开始支持多文档事务，但性能和成熟度与关系型数据库相比仍有差距。
- 高度关联的复杂报表：数据之间关系极多，查询需要大量JOIN。MongoDB虽然支持$lookup，但性能与复杂度和SQL比差很多。
- 固定结构化数据、强Schema约束：比如税务系统、财务系统，字段几十年不变，关系型数据库的约束能力反而是优势。
一句话总结选型逻辑：数据是自包含的、结构会变化的、写入规模会暴涨的，就选MongoDB；数据是强关联的、需要复杂事务的、结构极度稳定的，老老实实用关系型数据库。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心特性拆解：文档模型、复制集与分片
2.1 文档模型与BSON：为什么说它"像JSON又不是JSON"
MongoDB的文档存储在BSON（Binary JSON）格式中。BSON是JSON的二进制序列化版本，设计目标有两个：一是提高序列化和反序列化效率，二是在JSON的基础上扩展了数据类型。
BSON比JSON多出来的类型很关键。最常用的就是ObjectId，它是24位十六进制字符串，12字节结构包含时间戳、机器标识、进程ID和自增计数器。这个设计让MongoDB可以在分布式环境下不依赖中心节点生成全局唯一ID。实际编码时你会发现，直接用ObjectId生成主键，比自己在应用层用UUID或雪花算法省事得多，而且它自带时间序，按_id排序就能近似按创建时间排序。
BSON还支持Date类型、Decimal128高精度小数、Binary Data、正则表达式等。这里有个特别容易踩坑的点：如果你用字符串存日期，排序和范围查询会出问题，因为字符串排序是按字典序的，"2024-01-02"和"2024-1-2"顺序会乱。所以从第一天起就老老实实用Date类型，别图省事存字符串。
再说嵌套文档和数组，这是MongoDB最强大的能力。一条文档可以嵌套多层子文档，可以包含数组，数组里还能再嵌套文档。你可以在数组字段上建多键索引（Multikey Index），实现对数组内容的快速查询。比如一个博客文章文档里有tags数组，你给tags建索引后，查询"包含MongoDB标签的文章"就会走索引。
但是注意，BSON文档大小有16MB上限（单个文档），嵌套层级过深也会影响查询性能。我在设计文档结构时，一般会控制嵌套不超过三层，数组元素不超过几百个。超过这个量级，说明这个字段应该拆成单独的集合，或者是你的数据模型设计有问题。
2.2 复制集：高可用的真正含义
复制集（Replica Set）是MongoDB高可用的基石。一个复制集通常由一主多从组成，主节点负责读写，从节点负责复制数据并提供读能力（也可以配置成只读）。
很多人把复制集简单理解为主从备份，其实关键在于自动故障转移。当主节点心跳丢失超过10秒（默认配置），复制集会通过选举机制选出一个新的主节点，整个过程对应用层尽量透明。这意味着你的数据库在硬件故障、网络分区、机房抖动的情况下，能自动恢复写入能力，而不是等运维半夜爬起来手动切换。我经历过一次云主机宕机，复制集自动完成主从切换，业务中断时间不到30秒，这在传统主从方案里几乎不可能。
关于复制集有几个配置要点必须知道：
- 官方推荐奇数个投票节点，比如一主两从，这样在脑裂场景下能通过多数派选举避免出现双主。
- 可以给从节点设置priority和tags，控制谁更适合成为主节点。比如把配置更高的节点设priority为2，让它优先被选为主。
- 写关注级别（write concern）决定主节点在返回写入成功前需要等待多少节点确认。默认w=1表示主节点写入即返回，如果想要更高的数据安全，可以设置w="majority"。
我见过很多团队的复制集配置是"裸奔"的：只有一主一从，writeConcern默认，readPreference默认只读主节点。这种情况如果主节点挂了，虽然能自动切换，但切换窗口内可能丢数据，而且从节点完全没分担读压力。正确做法是：生产环境至少一主两从，核心业务写入设置w=majority，读多写少的场景把读请求分流到从节点（readPreference=secondaryPreferred）。
还有一个经常被忽略的点：复制集不是备份。如果有人误执行了dropDatabase，这个操作会通过oplog同步到所有从节点，你的备份同样会被删。复制集解决的是高可用问题，不是数据容灾问题。备份必须单独做，这个我后面专门讲。
2.3 分片集群：水平扩展的代价与回报
当单机数据量超过物理硬件的承载能力（通常单机几TB到几十TB），或者写入吞吐超过单节点的处理上限，就该考虑分片集群了。MongoDB的分片集群架构包含三个核心组件：mongos路由节点、config server配置服务、shard分片节点。
分片的核心是分片键（Shard Key）。MongoDB根据分片键的值，把数据分散到不同的分片上。分片键的选择是整个分片集群设计中最关键、也最容易犯错的地方。
分片键的设计原则：
- 高基数：分片键的取值必须足够分散，如果只有几个值，数据会全部堆在几个分片上，完全失去水平扩展的意义。
- 低频率：分片键的值不能被某个热点数据集中访问，比如用用户ID做分片键，如果某几个大用户贡献了90%的流量，那这几个大用户所在的分片就会成为热点。
- 不能修改：分片键一旦选定，就不能更改，所以要非常谨慎。
常见的分片键选择有：基于范围分片（Range Sharding）适合按时间范围查询的场景，但容易产生热点（新数据总是写同一个分片）；基于哈希分片（Hashed Sharding）让数据均匀分布，写入吞吐高，但范围查询无法路由到单个分片，需要在mongos层做广播查询。
我的建议是：大部分业务场景选哈希分片，尤其是写入密集的日志、行为数据。如果你的业务有明确的范围查询需求并且能接受一定程度的热点，再考虑范围分片。另外，如果经常用组合条件查询，可以考虑组合分片键，但实际效果取决于业务访问模式。
再强调一下分片的代价：分布式事务的复杂度飙升、聚合操作可能变成MapReduce式的广播查询、全局唯一索引受限、备份恢复方案更复杂。所以分片是"最后的手段"，不是"为了分片而分片"。我见过有团队数据量才几百GB就搞分片，结果运维复杂度翻了十倍，收益几乎为零，这是典型的技术过度设计。
3. 从零到一：部署、建模与CRUD实战
3.1 环境准备与部署要点
先给一套经过生产验证的Debian/Ubuntu环境安装流程。MongoDB官方提供了apt源，不要用系统自带的旧版仓库。
bash复制# 导入MongoDB公钥
curl -fsSL https://www.mongodb.org/static/pgp/server-7.0.asc | \
sudo gpg -o /usr/share/keyrings/mongodb-server-7.0.gpg \
--dearmor
# 创建源列表文件
echo "deb [ signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg ] \
http://repo.mongodb.org/apt/debian bullseye/mongodb-org/7.0 main" | \
sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list
# 安装
sudo apt-get update
sudo apt-get install -y mongodb-org
安装完成后，几个关键配置一定要改。打开/etc/mongod.conf：
yaml复制# 绑定内网IP，不要绑0.0.0.0
net:
port: 27017
bindIp: 127.0.0.1,192.168.1.10
# 启用认证
security:
authorization: enabled
# 复制集名称（如果要搭复制集）
replication:
replSetName: rs0
部署里最容易犯的错误是裸奔。MongoDB默认不开启认证，bindIp默认是127.0.0.1，但很多人改bindIp到0.0.0.0后忘了开认证，结果数据库直接暴露在公网，被勒索病毒删库的案例每年都有。装完第一件事就是创建管理员账号：
javascript复制use admin
db.createUser({
user: "admin",
pwd: "强密码",
roles: [ { role: "root", db: "admin" } ]
})
然后启用认证，重启服务。千万别存弱密码，MongoDB的扫描器在公网上24小时不间断扫27017端口。
生产环境我还建议开启审计日志和慢查询日志。慢查询的阈值我一般设置100ms，超过这个时间的操作都值得分析。
3.2 文档建模：从订单场景看设计思路
文档建模是MongoDB使用里最见功力的一环。很多人刚上手时习惯按关系型数据库的思路把数据拆成多张表，然后用$lookup去关联，这完全用错了MongoDB。
我用一个电商订单场景来对比两种建模思路。
关系型建模方式：订单表、订单明细表、用户表、商品表、物流表，五张表，查询订单详情要四表JOIN。
MongoDB推荐的方式：一条订单文档包含全部信息。
json复制{
"_id": ObjectId("..."),
"orderNo": "ORD20240115001",
"userId": ObjectId("..."),
"status": "PAID",
"items": [
{
"skuId": ObjectId("..."),
"name": "无线鼠标",
"price": NumberDecimal("129.00"),
"quantity": 2
},
{
"skuId": ObjectId("..."),
"name": "机械键盘",
"price": NumberDecimal("399.00"),
"quantity": 1
}
],
"totalAmount": NumberDecimal("657.00"),
"shippingAddress": {
"receiver": "张三",
"phone": "138****1234",
"province": "广东省",
"city": "深圳市",
"detail": "南山区科技园"
},
"createdAt": ISODate("2024-01-15T10:30:00Z")
}
这个设计的好处是显而易见的：查询订单详情只需要一次主键查询，不用JOIN。订单数据自包含，不会出现订单明细因为关联表数据丢失而查不到的情况。商品名称、价格在订单快照里，即使商品后续改价，历史订单的展示数据也不受影响。
再来看嵌入（Embedding）和引用（Referencing）的权衡：
- 嵌入适合：子数据始终和父数据一起读、子数据量有限（如订单明细、收货地址）、子数据不需要独立访问。
- 引用适合：子数据会被多个父文档共享（如商品信息、用户信息）、子数据量无法预估会无限增长（如订单列表关联的用户）。
一个经验法则：如果两个对象总是一起查询、一起修改，就嵌入；如果它们各自有独立的生命周期和查询场景，就引用。
有个建模错误我见得太多了：在数组字段上不加限制地push数据。比如在一个"用户文档"里维护用户的所有操作日志，数组越来越大，最终超过16MB文档上限。这种"文档内无限增长"的字段必须拆出去，用单独集合维护。
3.3 CRUD与聚合管道：真正高频的日常操作
基础CRUD直接上代码，都是高频操作。
javascript复制// 插入单条
db.users.insertOne({
name: "李四",
email: "lisi@example.com",
tags: ["vip", "2024"],
createdAt: new Date()
})
// 批量插入
db.users.insertMany([
{ name: "王五", email: "wangwu@example.com" },
{ name: "赵六", email: "zhaoliu@example.com" }
])
// 查询-条件+投影
db.users.find(
{ tags: "vip", createdAt: { $gte: ISODate("2024-01-01") } },
{ name: 1, email: 1, _id: 0 }
)
// 更新-操作符
db.users.updateOne(
{ email: "lisi@example.com" },
{ $set: { level: 2 }, $push: { tags: "renew" } }
)
// 删除
db.users.deleteMany({ status: "INACTIVE" })
增删改查不难，真正值得花时间掌握的是聚合管道（Aggregation Pipeline）。它是MongoDB处理数据的核心武器，能在一个管道里完成过滤、分组、排序、计算、关联。我用一个实际场景来演示：统计每个月的订单金额和订单数。
javascript复制db.orders.aggregate([
{
$match: {
createdAt: { $gte: ISODate("2024-01-01"), $lte: ISODate("2024-12-31") },
status: { $ne: "CANCELLED" }
}
},
{
$group: {
_id: { $dateToString: { format: "%Y-%m", date: "$createdAt" } },
totalAmount: { $sum: "$totalAmount" },
orderCount: { $sum: 1 },
avgAmount: { $avg: "$totalAmount" }
}
},
{ $sort: { _id: 1 } }
])
聚合管道的阶段可以灵活组合，性能上要注意：能通过$match提前过滤的数据尽量在管道最前面过滤，减少后续阶段的数据量。$lookup是性能杀手，能不用尽量不用，如果数据结构设计合理，大多数场景根本不需要$lookup。
再说一个很实用的技巧：用$setWindowFields做移动平均和累计值。比如实时统计当天每小时的订单量，并对前一小时做同比，这类分析用聚合管道一条语句就能出结果。
4. 索引、性能与查询优化实战
4.1 索引原理与设计策略
MongoDB使用B-Tree索引结构（相比MySQL的InnoDB B+Tree，本质上是类似的树形结构），支持单字段索引、复合索引、多键索引、文本索引、地理空间索引、哈希索引等。
索引设计的原则，先记住一条：索引是为查询服务的，不是越多越好。每个索引占磁盘空间，每次写入都要更新索引，索引过多会拖慢写入。我见过一个表建了20个索引，写入性能惨不忍睹，查询也没快多少，因为真正被用到的索引就三四个。
复合索引设计是最需要动脑子的。核心原则是"等值查询字段在前、排序字段在后、范围查询字段最后"。比如你最常跑的查询是：
javascript复制db.orders.find({ userId: "u123", status: "PAID" }).sort({ createdAt: -1 })
针对这个查询，复合索引应该设计为：
javascript复制db.orders.createIndex({ userId: 1, status: 1, createdAt: -1 })
等值查询的userId和status放在前面，排序字段createdAt放最后，并且方向与排序方向一致，这样MongoDB可以直接走索引完成排序，不需要再内存排序。
还有一个很多人不知道的点：索引前缀原则。如果你建了复合索引{A:1, B:1, C:1}，那么{A}和{A,B}的查询都可以使用这个索引，但{B}或{C}的查询用不上。所以尽量设计一个覆盖面广的复合索引，而不是每个查询建一个索引。
4.2 慢查询与执行计划分析
排查性能问题，第一步是找到慢查询。开启慢查询日志：
javascript复制db.setProfilingLevel(1, { slowms: 100 })
设置后，超过100ms的操作会记录到system.profile集合。然后查询慢日志：
javascript复制db.system.profile.find({
op: { $in: ["query", "command"] },
millis: { $gt: 100 }
}).sort({ ts: -1 }).limit(20)
找到慢查询后，用explain分析执行计划：
javascript复制db.orders.find({ userId: "u123", status: "PAID" }).sort({ createdAt: -1 }).explain("executionStats")
看执行计划时，重点关注这几个指标：
- winningPlan：最终选择的执行计划。
- stage：如果是COLLSCAN，说明全表扫描，必须建索引；如果是IXSCAN，说明走了索引。
- totalDocsExamined：实际扫描的文档数，如果这个数远大于返回的结果数，说明索引选择性不好。
- executionTimeMillis：执行耗时。
- docsExamined与keysExamined：前者是扫描文档数，后者是扫描索引条目数，理想情况是两者接近返回数量。
我之前排查过一个真实案例：一个订单查询接口，从100ms慢慢涨到2秒，最后接口超时。explain一看，stage是COLLSCAN，全表扫描。原因是有一次上版本时，代码改了查询条件，新的查询条件没有对应的索引。加了一个复合索引后，查询直接降到20ms。这种问题如果不开慢日志，光靠用户报障，排查周期会非常长。
4.3 常见性能陷阱及规避方案
我总结几个生产环境最常见的性能陷阱：
- 无索引查询。这个最基础但也最常见，尤其是新功能上线忘了加索引，或者查询条件字段顺序变了导致索引失效。
- 索引选择性差。比如给一个只有两个值的字段建索引（status: true/false），查询时MongoDB可能干脆弃用索引走全表扫描，因为走索引的成本更高。
- 文档过大。单条文档几十MB，查询时IO开销巨大。解决方案是拆文档，把大字段独立到单独集合。
- 数组字段的$in查询。如果数组长度大且频繁更新，性能会很差。尽量控制数组长度。
- 使用$where和$function做正则或自定义函数过滤。这类查询无法使用索引，性能极差，能避免就避免。
- 数据库连接数打满。连接池配置过小导致大量请求排队，解决方法是调大连接池上限和检查是否有连接泄漏。
再补充一个高频坑：正则查询的写法。很多人喜欢用db.users.find({ name: /张/ })做模糊搜索，这种查询如果没加^前缀锚定，会进行全表扫描。正确姿势是给搜索字段建立文本索引（Text Index），用$text搜索，或者用/^张/前缀正则，这样才有可能走索引。
5. 实战踩坑记录：运维与开发中的那些坑
5.1 磁盘与存储引擎的坑
MongoDB默认的存储引擎是WiredTiger，它有两个显著特点：写入时预分配磁盘空间、删除数据后磁盘空间不自动回收。
这个"空间不回收"的特性坑过很多人。你删了100GB数据，db.stats()显示数据量小了，但df -h看磁盘占用一点没少。这不是Bug，是WiredTiger的设计——删除数据产生的空闲空间会被后续写入复用，但不会立刻归还给操作系统。
后果就是：如果你在一个大数据集上做大批量删除，然后长期不写新数据，磁盘占用会居高不下，甚至导致磁盘满。解决方案有两个：
- 执行compact命令回收空间，但这是个重操作，会阻塞数据库，必须在维护窗口执行。
- 提前规划数据保留周期，定期归档老数据到冷存储，保持数据集稳定在一个可控范围内。
WiredTiger还有一个特点是读多写少的场景有写放大问题。它的快照隔离和版本链机制导致更新一个文档可能需要写多个版本，加上索引更新，实际磁盘写入量可能是逻辑写入量的数倍。所以在SSD上跑MongoDB是标配，机械盘做写密集业务基本扛不住。
5.2 备份恢复与数据一致性
前面我强调过，复制集不等于备份。生产环境的备份方案，我推荐两套组合拳：
第一套：mongodump逻辑备份 + 定时任务。适合中小规模数据，恢复灵活，但恢复时间较长。
bash复制mongodump --uri="mongodb://user:pass@localhost:27017" \
--db=orders --out=/backup/orders_$(date +%Y%m%d)
第二套：文件系统快照 + Oplog增量备份。适合大数据量，恢复速度快。用LVM或云厂商快照，配合oplog增量恢复到任意时间点。
bash复制# 使用mongodump的oplog选项做增量
mongodump --uri="mongodb://user:pass@localhost:27017" \
--oplog --out=/backup/oplog_$(date +%Y%m%d)
备份恢复还要考虑数据一致性：MongoDB是分布式系统，数据分布在多个分片，备份必须保证所有分片在同一时间点的一致性。生产环境我用的是全局快照方案：在config server开启快照，然后对每个分片做一致时间点的快照。
还有一个恢复演练的问题。很多团队备份是做了，但从没恢复过，直到灾难发生才发现备份文件损坏、版本不兼容、恢复时间太长。我的建议是：每个季度至少做一次完整的恢复演练，并且把恢复时间目标（RTO）写进运维文档。数据恢复这事儿，不能等火烧眉毛了才第一次试。
5.3 版本升级与驱动兼容性
MongoDB服务端版本的升级节奏，我建议不要盲目追新，也不要长期停留在超老版本。社区支持策略是：当前主版本和上一个大版本提供长期技术支持。比如当前是7.0，那么6.0和7.0是主流支持范围，5.0及以下的版本应该尽快升级。
升级前必做的三件事：
- 查兼容性矩阵：官方文档有详细的版本兼容表，特别是驱动和工具的兼容性。有一个热搜词是"mongodb switch branches"，这就是在说MongoDB的版本分支切换，其实官方仓库里，不同版本的源和APT源分支是分开管理的，升级时改一下源里的版本号就行，但千万别直接跨大版本升级。
- 检查驱动版本：这是最容易翻车的。比如用pymongo的旧版本连MongoDB 7.0，可能在身份认证或序列化时直接报错。升级服务端前，先看驱动文档确认支持的最高版本。
- 备份和演练：升级前必须做完整备份，并在测试环境完成一次升级演练。
我遇到过的一个典型坑：排查一个"mongodb更新4.4.30 windows"的问题，用户在Windows上升级MongoDB到4.4.30，结果启动不了。原因是锁文件和旧日志的权限问题。Windows上升级MongoDB尤其要注意，先停止服务，备份数据目录，再卸载旧版本、安装新版本，最后用mongod --repair修复数据目录。跨大版本升级时还要跑一下db.upgradeCheckAllDBs()检查是否有不兼容的数据。
再说驱动的一个真实案例：有一个用C# MongoDB驱动写的服务，升级MongoDB服务端后，所有写入都报"BSON element 'xxx' is an invalid field name"之类的错误。排查半天发现是C#驱动版本太老，将BSON序列化规则升级后生成的字段名包含了新版本不允许的字符。升级C#驱动到对应版本后恢复正常。所以我的经验是：服务端升级和驱动升级必须同步评估，别只升一个。
热词里还有"mongodb 查list包含"，这其实是个很常见的查询需求——查询数组字段是否包含某个值。正确写法：
javascript复制// 查询tags数组包含"vip"的文档
db.users.find({ tags: "vip" })
// 查询tags数组同时包含"vip"和"2024"
db.users.find({ tags: { $all: ["vip", "2024"] } })
// 查询tags数组包含"vip"或"2024"
db.users.find({ tags: { $in: ["vip", "2024"] } })
这个操作要配合多键索引，建索引的方法：db.users.createIndex({ tags: 1 })，否则数组越大，查询越慢。
最后再分享两个小技巧。
第一个是批量写入一定要用bulkWrite，不要用for循环insertOne。一次bulkWrite可以混合insert、update、delete，并且按顺序执行，网络往返次数从N次降到1次，性能提升非常明显。我优化过一个数据导入服务，改成bulkWrite后，导入时间从40分钟降到3分钟。
第二个是连接字符串里的参数别乱加。很多人从网上复制一段连接串，里面带上了retryWrites=true和w=majority，结果在单机环境（非复制集）下连接直接报错。连接串参数要跟你的部署架构匹配。单机开发环境就用最简单的那行：mongodb://localhost:27017/mydb，复制集环境再往上加参数。
MongoDB这套技术栈，说难不难，说简单也不简单。它的核心价值在于让你的数据模型跟业务模型对齐，让水平扩展和高可用成为数据库的内建能力而不是外部补丁。但所有便利都有代价：你需要重新建立一套建模思维，需要更精细地管理索引和查询，需要习惯磁盘空间不自动回收这类和传统数据库不同的行为。把这些都摸透了，MongoDB会是你在业务快速迭代阶段最顺手的存储方案之一。