Mongo数据库更新那些事儿，怎么快速搞定提升存储效率不慌乱

说到MongoDB数据库更新,很多刚开始接触的朋友可能会觉得有点无从下手，尤其是当数据量大了以后，怎么更新才能又快又好，不让数据库“卡壳”，确实是个值得琢磨的事儿，今天咱们就抛开那些让人头疼的专业术语，用大白话聊聊怎么快速搞定MongoDB更新，提升存储效率，让你心里有底不慌乱。

咱们得明白更新的核心是“精准”，你想想，如果你要在一个人山人海的广场上找一个穿红衣服的人，是拿着大喇叭喊名字快，还是挨个扒拉人看脸快？肯定是喊名字快嘛，MongoDB也一样，更新操作要想快，最关键的就是让它能快速“找到”要更新的数据，这就全靠“索引”了。（来源：MongoDB官方文档关于索引重要性的阐述）

索引就像一本书的目录,没有目录，你想找某个章节，得从头一页一页翻，累死个人，有了目录，你直接翻到对应页码就行了，在MongoDB里，给你经常用来查询和更新的字段建上索引，比如用户ID、订单号、创建时间这些，数据库引擎就能直接“定位”到那条数据，更新起来自然嗖嗖的，千万别小看这个，这是提升更新速度最立竿见影的一招，索引也不是越多越好，建多了会影响数据写入的速度，就像一本书目录太详细，编目录的人也挺累的，你得根据实际查询和更新的模式，建那些最常用的索引。

更新操作本身也有讲究,MongoDB提供了很多更新操作符，用对了能省不少事，咱们要更新一个用户的积分，笨办法是先把这个用户的数据整个查出来，在程序里把积分改好，然后再把整条数据写回去，这就好比你要给一篇文章改个错别字，却把整篇文章重新抄写了一遍，效率太低了。（来源：MongoDB官方文档关于更新操作符的介绍）

聪明做法是用$inc这样的操作符，直接告诉数据库：“找到那个用户，把他的积分字段增加10”，命令一下，数据库直接在硬盘上把那个数字改了，省去了来回传输和替换整个文档的开销，类似的还有$set用来修改某个字段的值，$push给数组添加一个元素等等，这种“定向”更新，不仅速度快，还能减少网络传输的数据量，对整体性能提升帮助很大，特别是当你的文档很大，但每次只更新其中一小部分时，这个优势特别明显。

再说说批量更新,如果你要更新成百上千条符合条件的数据，一条一条地发更新命令，那数据库光接你的请求就忙不过来了，就像收银台前排了一大堆人，每个人只买一瓶水，还都要单独结账，收银员肯定崩溃。（来源：数据库操作最佳实践中的批量处理原则）

这时候,就要用批量更新，MongoDB支持一次更新多个文档，你用一个更新条件，能匹配上的所有文档都一起被处理，这就像是超市搞促销，所有这个牌子的水一起打折，效率一下就上去了，不过这里要注意，批量更新虽然快，但也是个“大动作”，搞不好会影响数据库同一时间的其他操作，对于非常大量的更新，最好在业务低峰期（比如半夜）分批进行，别在大家正用着系统的时候“兴风作浪”。

文档的设计也直接影响更新效率,MongoDB是文档型数据库，一个文档就像一个小型的JSON对象，它鼓励你把经常要一起用的数据放在一个文档里，但也不是什么都往里塞就是好的，你要记录用户的每次登录日志，如果把这些日志都作为数组塞进用户的主文档里，那么这个文档就会变得无比巨大，每次新增一条日志，都要更新整个庞大的文档，速度肯定会慢下来，而且文档大小还有限制。（来源：MongoDB官方文档关于数据模型设计的建议）

更聪明的做法是把日志拆分成独立的集合（Collection），通过用户ID来关联，这样更新日志就是新增一个小文档，对主用户文档毫无影响，这就是所谓的“嵌入式文档”和“引用式文档”的选择问题，基本原则是：如果子数据经常和父数据一起查询，且数量不大，就嵌入式；如果子数据数量可能无限增长，或者经常独立操作，就引用式，设计好了，更新效率自然高。

别忘了定期“打扫卫生”，数据库用久了，会产生很多碎片，就像你的电脑硬盘，长时间不整理，文件东一块西一块，读写速度就慢了，MongoDB虽然有自己的内存管理和存储引擎（比如WiredTiger）来自动处理一部分碎片，但对于频繁更新、删除操作的集合，碎片化还是会比较严重。（来源：MongoDB性能优化指南中关于压缩和碎片整理的内容）

这时候,可以考虑在业务低峰期对集合进行“压缩”或者“重整”，比如使用compact命令（针对WiredTiger引擎），它能释放磁盘空间，重整数据文件，让后续的读写操作更快，这就好比给数据库做了一次大扫除，清除了垃圾，东西都摆回了原位，找起来当然顺手。

想让MongoDB更新快、存储效率高，核心思路就是四句话：用索引快速定位，用操作符精准更新，用批量减少交互，用设计预防瓶颈，平时再养成定期维护的好习惯，你就能从容应对数据增长，不再为更新操作而慌乱，数据库优化是个持续的过程，多观察、多尝试，慢慢就能找到最适合自己业务场景的最佳实践。