MongoDB 从4.4到7.0各个版本新特性概览

发布时间：2025-11-05 02:45:03 来源：创站工坊 作者：域名

作者 | 吴守阳

审校 | 重楼

引言

在数据库技术日新月异的到各今天，MongoDB作为领先的个版概览NoSQL数据库之一，持续地推出新版本以满足不断变化的本新企业需求和技术挑战。从MongoDB 4.4至7.0，特性每一版都融入了创新特性，到各旨在提升性能、个版概览扩展性、本新安全性和易用性，特性同时也反映了行业趋势和用户反馈。到各

本文旨在全面剖析这些版本中的个版概览关键新特性，不仅是本新为了记录技术演进的历史，更是特性为了赋能数据库管理员、开发者和架构师，到各使他们能够充分理解并利用这些新功能，个版概览从而优化数据管理和应用性能。本新

速览

本文将从以下方面介绍数据库 MongoDB 4.4、5.0、6.0、7.0版本：

1.MongoDB4.4 新特性

2.MongoDB5.0 新特性

3.MongoDB6.0 新特性

4.MongoDB7.0 版本新特性

目的

读者获益

MongoDB的每个版本发布新特性都是为了响应不断变化的市场需求、技术进步以及用户反馈，旨在提高数据库的性能、可靠性、安全性、易用性和功能丰富度。以下是一些关键版本及其新特性的背景和带来的好处：

一、MongoDB 4.4版本新特性

MongoDB 4.4版本中新增了隐藏索引，众所周知数据库维护太多的索引会导致写性能下降，但是往往业务上的复杂性导致了运维人员不敢轻易去删除一个潜在的低效率索引，担心误删除会带来业务性能的抖动，WordPress模板而重建索引的代价也非常大。

为了解决上述问题。该功能支持通过collMod命令隐藏现有的索引，保证该索引在后续的查询中不会被使用。在观察一段时间后，确定业务没有异常即可以放心删除该索引。

MongoDB4.4版本中，你可以通过refineCollectionShardKey命令给现有的Shard Key增加一个或多个Suffix Field来改善现有的文档在Chunk上的分布问题。例如在订单业务场景中，通过refineCollectionShardKey命令把Shard key更改为{customer_id:1, order_id:1}，即可避免单一分片上的访问热点问题。

并且，refineCollectionShardKey命令的性能开销非常低，仅更改Config Server节点上的元数据，不需要任何形式的数据迁移，数据的打散仍然在后续正常的Chunk自动分裂和迁移的流程中逐步进行。

此外，Shard Key需要有对应的Index来支撑，因此refineCollectionShardKey命令要求提前创建新Shard Key所对应的Index。

由于并不是所有的文档都存在新增的Suffix Field，因此在4.4版本中隐式支持了Missing Shard Key功能，即新插入的文档可以不包含指定的Shard Key Field。但是由于很容易产生Jumbo Chunk，因此并不建议使用。

在最新的4.4版本中加入了复合哈希索引，即你可以在复合索引中指定单个哈希字段，位置不限，可以作为前缀，也可以作为后缀，进而也就提供了对复合哈希片键的支持。

页面的响应速度和经济损失直接挂钩。Google有一个研究报告表明，如果网页的加载时间超过3秒，用户的跳出率会增加50%。针对这个问题，MongoDB在4.4版本中提供了Hedged Reads功能，即在分片集群场景下，mongos节点会把一个读请求同时发送给某个分片的两个副本集成员，然后选择最快的返回结果回复客户端，来减少业务上的P95（指过去十秒内95%的请求延迟均在规定范围内）和P99延迟（指过去十秒内99%的请求延迟均在规定范围内）。

Hedged Reads功能作为Read Preference参数的一部分来提供，因此可以在Operation粒度上进行配置。当Read Preference指定为nearest时，系统默认启用Hedged Reads功能；当指定为primary时，不支持Hedged Reads功能；当指定为其他时，需要显式地指定hedgeOptions才可以启用Hedged Reads。如下所示：

此外，Hedged Reads也需要mongos开启支持，配置readHedgingMode参数为on，使mongos开启该功能支持。

参考代码：

4.4 之前的版本中，索引的创建需要在主库中完成之后，才会到备库上执行。备库上的创建动作在不同的版本中，因为创建机制和创建方式的不同，对备库Oplog的影响也大有不同。

但即使在4.2版本中统一了前后台索引创建机制，使用了相当细粒度的加锁机制（只在索引创建的开始和结束阶段对集合加独占锁），也会因为索引创建本身的CPU、IO性能开销导致复制延迟，或是因为一些特殊操作，例如使用collMod命令修改集合元信息，而导致Oplog的应用阻塞，甚至会因为主库历史Oplog被覆盖而进入Recovering状态。

在4.4版本中，主库和备库上的索引创建操作是同时进行的，这样可以大幅减少上述情况所带来的主备延迟，即使在索引创建过程中，也可以保证备库访问到最新的数据。

此外，新的索引创建机制规定，只有在大多数具备投票权限节点返回成功后，索引才会真正生效。所以，也可以减轻在读写分离场景下因为索引不同而导致的性能差异。

在4.4版本中，MongoDB针对上述问题实现了Mirrored Reads功能，即主节点会按一定的比例把读流量复制到备库上执行，来帮助备库预热缓存。这是一个非阻塞执行（Fire and Forgot）的行为，不会对主库的性能产生任何实质性的影响，但是备库负载会有一定程度的上升。

流量复制的比例是可动态配置的，通过mirrorReads参数设置，默认复制1%的流量。

此外，还可以通过db.serverStatus( { mirroredReads: 1 } )来查看Mirrored Reads相关的统计信息，如下所示：

在4.4版本中，MongoDB支持通过storage.oplogMinRetentionHours参数定义需要保留的Oplog时长，也可以通过replSetResizeOplog命令在线修改这个值。参考代码如下：

二、MongoDB 5.0版本新特性

创建时间序列数据集合的命令示例：

数据库版本

特点

实现方法

MongoDB 5.0以前

重新分片过程复杂且需要手动分片。

方法一：先dump整个集合，然后用新的分片键把数据库重新加载到一个新的集合中。

由于这是一个需要离线处理的过程，因此你的应用程序在重新加载完成之前需要中断停服较长时间。例如：在一个三分片的集群上dump和重新加载一个10 TB以上的集合可能需要几天时间。

方法二：新建一个分片集群并重新设定集合的分片键，然后通过定制迁移方式，将旧分片集群中需要重新分片的集合，按新的分片键写入到新的分片集群中。

该过程需要你自行处理查询路由和迁移逻辑、不断检查迁移进度，以确保所有数据迁移成功。

定制迁移是高度复杂的、劳动密集型的、有风险的任务，而且耗时很长。例如：某个MongoDB用户花了三个月才完成100亿个document的迁移。

MongoDB 5.0开始

运行reshardCollection命令即可启动重新分片。

重新分片的过程高效。

并不是简单地重新平衡数据，而是在后台将所有当前集合的数据复制并重新写入新集合，同时与应用程序新的写入保持同步。

重新分片是完全自动化的。

将重新分片花费的时间从几周或几个月压缩到几分钟或几小时，避免了冗长繁杂的手动数据迁移。

通过使用在线重新分片，可以方便地在开发或测试环境中评估不同分片键的效果，也可以在你需要时修改分片键。

你可以在业务运行（数据不断增长）的情况下，按需改变集合的分片键（Shard key），而不需要数据库停机或在数据集合中进行复杂的迁移。你只需要在MongoDB Shell中运行reshardCollection命令，选择你需要重新分片的数据库和集合，指定新的分片键即可。

reshardCollection: "<database>.<collection>", key: <shardkey>

说明

<database>：需要重新分片的数据库名称。

<collection>：需要重新分片的集合名称。

<shardkey>：分片键的名称。

当你调用reshardCollection命令时，MongoDB会克隆现有集合，然后将现有集合中所有oplog应用到新集合中，当所有oplog被使用后，MongoDB会自动切换到新集合，并在后台删除旧集合。

从MongoDB 5.0开始，Write Concern默认级别为majority，仅当写入操作被应用到Primary节点（主节点）且被持久化到大多数副本节点的日志中的时候，才会提交并返回成功，“开箱即用”地提供了更强的数据可靠性保障。

Write Concern是完全可调的，你可以自定义配置Write Concern，以平衡应用程序对数据库性能和数据持久性的要求

默认情况下，一个客户端连接对应后端MongoDB服务器上的一个线程（net.serviceExecutor配置为synchronous）。创建、切换和销毁线程都是消耗较大的操作，当连接数过多时，线程会占用MongoDB服务器较多的资源。

连接数较多或创建连接失控的情况称为“连接风暴”，产生该情况的原因可能是多方面的，且经常是在服务已经受到影响的情况下发生。

针对这些情况，MongoDB 5.0采取了以下措施：

以上措施，加上之前版本在mongos查询路由层的改进，进一步提升了MongoDB承受高并发负载的能力。

长时间运行的快照查询（Long-Running Snapshot Queries）增加了应用程序的通用性和弹性。你可以通过该功能运行默认时间为5分钟的查询（或将其调整为自定义持续时间），同时保持与实时事务性数据库一致的快照隔离，也可以在Secondary节点（从节点）上进行快照查询，从而在单个集群中运行不同的工作负载，并将其扩展到不同的分片上。

MongoDB通过底层存储引擎中一个名为Durable history的项目实现了长期运行的快照查询，该项目早在MongoDB 4.4中就已实现。Durable history将存储自查询开始以来所有变化的字段值的快照。通过使用Durable history，查询可以保持快照隔离，即使在数据发生变化的情况下，Durable history也有助于降低存储引擎的缓存压力，使得业务可以在高写入负载的场景下实现更高的查询吞吐量。

为了提供更好的用户体验，MongoDB 5.0从头开始重新设计了MongoDB Shell（mongosh），以提供一个更现代化的命令行体验，以及增强可用性的功能和强大的脚本环境。新版MongoDB Shell已经成为MongoDB平台的默认Shell。新版MongoDB Shell引入了语法高亮、智能自动完成、上下文帮助和有用的错误信息，为你创造一个直观、互动的体验。

MongoDB 5.0支持将正在进行中的索引创建任务在节点重新启动后自动恢复至原来的位置，减少计划中维护动作对业务的影响。例如：重新启动或升级数据库节点时，你不需要担心当前正在进行的大集合索引创建任务失效。

三、MongoDB 6.0版本新特性

可查询加密功能目前是预览（Preview）版本，不建议直接在生产环境使用。预览（Preview）版本的更多信息，请参见MongoDB Releases Queryable Encryption Preview。

MongoDB 6.0新推出可查询加密功能，允许用户从客户端加密敏感数据，将其作为完全随机的加密数据存储在数据库服务器端，并对加密数据进行丰富的查询。

可查询加密只允许在客户端查看敏感数据的明文，在查询到达服务器端时会同时包含从KMS获取的加密密钥，然后在服务器端以密文进行查询并返回，最后在客户端利用密钥解密后以明文呈现。

可查询加密的特点如下：

无论是数据的同构同步（Mongo-to-Mongo）还是异构同步（Others-to-Mongo & Mongo-to-Others）都是MongoDB生态中的一部分，开源MongoDB推出了多种工具，比如mongoimport、mongoexport、mongodump和mongorestore等，但是这些工具并没有很好的规划数据同步。

MongoDB 6.0推出了新的同步工具mongosync，它能支持跨实例数据同步（两个MongoDB实例间连续且单向的数据同步）。用户还可以实时控制和监控整个同步过程，按需启动、停止、恢复甚至反转同步。

分别从索引、查询以及排序多个方面增强了时序集合。

聚合功能允许用户处理多个文档并返回计算结果。通过将多个操作符组合到聚合管道中，用户可以构建出足够复杂的数据处理管道以提取数据并进行分析。MongoDB 6.0在原有聚合功能的基础上，推出了如下新特性以及优化项：

新增$maxN、$topN、$minN、$bottomN、$lastN和$sortArray等操作符。通过操作符可以将更多的计算从业务层下沉到数据库中，使得业务层更加轻量化。

MongoDB 6.0在原有弹性的基础上，推出了如下新特性以及优化项：

你可以通过configureCollectionBalancing命令设置自动整理磁盘碎片，设置自动整理后你无需再主动使用compact命令来整理磁盘空间碎片，即可有效控制磁盘空间使用率

MongoDB 6.0在原有安全性的基础上，对客户端字段级加密（CSFLE, Client-Side Field-Level Encryption）功能进行了优化。CSFLE将支持任何符合密钥管理互通协议（KMIP，Key Management Interoperability Protocol）的密钥管理提供商，即除了基于KeyFile的本地密钥管理外，MongoDB支持通过KMIP与第三方密钥管理设备集成，为用户提供更安全的保障。

四、MongoDB 7.0版本新特性

MongoDB 7.0版本中新增了checkMetadataConsistency命令，以检查不同分片中元数据不一致的情况，示例如下。

示例1：

示例2：

你可以在日常运维中增加该巡检项，尽早发现可能不一致的风险。更多信息请参见checkMetadataConsistency。

支持基于采样查询（Sampled queries）的结果来分析集合的分片键是否合理，可以帮助你更好地设计Schema以及分片键、更合理使用分片架构。核心命令analyzeShardKey的语法如下：

尽管该命令并不会阻塞集合上的读写操作，但为了降低对业务的影响，建议配套使用secondary或secondaryPreferred模式的Read preference执行。mongos默认为secondaryPreferred模式。

更多信息请参考analyShardKey与configureQueryAnalyzer。

MongoDB 7.0为自动均衡器（Balancer）实现了一个新的自动合并器（AutoMerger），当数据或索引分布不均衡、存在过多分片或进行数据迁移时，自动合并器会合并Chunks，以均衡数据并提高性能。MongoDB 7.0默认开启该功能，你也可以通过Balancer活动窗口控制该功能。

之前版本引入用于单个集合数据均衡的configureCollectionBalancing命令也支持了AutoMerge：

除此之外，你也可以通过mergeAllChunksOnShard命令将一个分片上所有可合并的Chunk（或Range）进行手动合并：

除了上文提到过的AutoMerger以外，还有以下优化项：

Balancer不再依据分片间Chunks数量的差异，而是依据分片间数据量的差异进行均衡。

将Chunk的逻辑概念转为Range。

自动分裂（auto-splitting）只会在跨分片移动时发生。

下面的SQL将"myDB"更换为所需要查询的DB名称即可。

新增了以下操作符，支持位计算和百分位数：

字段名

描述

$bitAnd

返回Int或Long类型数值的按位与运算的结果。

$bitNot

返回Int或Long类型数值的按位取反运算结果。

$bitOr

返回Int或Long类型数值的按位或运算的结果。

$bitXor

返回Int或Long类型数值的按位异或运算的结果。

$median

返回近似中位数，相当于50百分位数。

$percentile

返回指定的百分位数。

作者介绍

吴守阳，51CTO社区编辑，拥有8年DBA工作经验，熟练管理MySQL、Redis、MongoDB等开源数据库。精通性能优化、备份恢复和高可用性架构设计。善于故障排除和自动化运维，保障系统稳定可靠。具备良好的团队合作和沟通能力，致力于为企业提供高效可靠的数据库解决方案。

相关文章