Query Behavior查询行为
Queries for null Don't Match undefined Fields对null的查询不匹配未定义的字段
Starting in MongoDB 8.0, comparisons to 从MongoDB 8.0开始,相等匹配表达式中与null in equality match expressions don't match undefined values.null的比较不匹配undefined的值。
For example, consider these documents and query:例如,考虑这些文档和查询:
// create the people collection创建人物集合
db.people.insertMany( [
{ _id: 1, name: null },
{ _id: 2, name: undefined },
{ _id: 3, name: [ "Gabriel", undefined ] },
{ _id: 4, names: [ "Alice", "Charu" ] }
] )db.people.find( { name: null } )
Prior to MongoDB 8.0, the preceding query would match documents where:在MongoDB 8.0之前,前面的查询将匹配以下文档:
Thenamefield isnull(_id: 1)name字段为null(_id: 1)Thenamefield isundefinedor contains anundefinedarray element (_id: 2and_id: 3)name字段为undefined或包含undefined的数组元素(_id: 2和_id: 3)Thenamefield does not exist (_id: 4)name字段不存在(_id: 4)
Starting in MongoDB 8.0, the preceding query does not match documents where the 从MongoDB 8.0开始,前面的查询与name field is undefined or contains undefined array elements. The query only matches documents where:name字段为undefined或包含undefined数组元素的文档不匹配。查询仅匹配以下文档:
Thenamefield isnullor contains anullarray element (_id: 1)name字段为null或包含null数组元素(_id: 1)Thenamefield does not exist (_id: 4)name字段不存在(_id: 4)
This query behavior change also impacts these operations:此查询行为更改也会影响以下操作:
To learn how to rewrite your queries or migrate your data to account for this behavior change, see Migrate Undefined Data and Queries.
Important
The undefined BSON type is deprecated. If you try to insert a document with the undefined JS type in mongosh, your deployment stores a null value. For more information, see the mongosh compatibility documentation.
Deprecations
| Deprecated | |
|---|---|
LDAP | Starting in MongoDB 8.0, LDAP authentication and authorization is deprecated. LDAP is available and will continue to operate without changes throughout the lifetime of MongoDB 8. LDAP will be removed in a future major release. For more details, see LDAP Deprecation. LDAP migration information will be available in the future. |
Hedged reads | Starting in MongoDB 8.0, hedged reads are deprecated. Queries that specify the read preference |
Index filters | Deprecated in version 8.0. Starting in MongoDB 8.0, use query settings instead of adding index filters. Index filters are deprecated starting in MongoDB 8.0. Query settings have more functionality than index filters. Also, index filters aren't persistent and you cannot easily create index filters for all cluster nodes. To add query settings and explore examples, see |
Server-side JavaScript functions | Starting in MongoDB 8.0, server-side JavaScript functions ( |
| MongoDB 8.0 deprecates the |
| MongoDB 8.0 deprecates the |
|
WarningStarting in MongoDB 8.0, use of the |
| MongoDB 8.0 deprecates the |
| Starting in MongoDB 8.0, the |
Backward-Incompatible Features
Cannot Connect Directly to Shard and Run Commands
Starting in MongoDB 8.0, you can only run certain commands on shards. If you attempt to connect directly to a shard and run an unsupported command, MongoDB returns an error:
"You are connecting to a sharded cluster improperly by connecting directly
to a shard. Please connect to the cluster via a router (mongos)."
To run a non-supported database command directly against a shard, you must either connect to mongos or have the maintenance-only directShardOperations role.
MongoDB supports online transition from a replica set to a 1-shard cluster by allowing commands to be run directly against a shard. However, once the cluster has more than one shard, only the listed commands can be run directly against the shard without the maintenance-only directShardOperations role.
Write Concern Majority
Starting in MongoDB 8.0, write operations that use the "majority" write concern return an acknowledgment when the majority of replica set members have written the oplog entry for the change. This improves the performance of "majority" writes. In previous releases, these operations would wait and return an acknowledgment after the majority of replica set members applied the change.
Oplog Buffers
Starting in MongoDB 8.0, secondaries write and apply oplog entries for each batch in parallel. This introduces a breaking change for the metrics.repl.buffer status metric, as it now provides information on two buffers instead of one.
MongoDB 8.0 deprecates the following server status metrics:
It replaces them with these metrics:
General Changes
Shutdown Performance
Starting in MongoDB 8.0, Bulk.insert() and data ingestion workloads may perform better. However, shutting down MongoDB immediately after running these workloads might take longer because of the extra data being flushed to disk.
Concurrent Compact Commands Not Allowed
Starting in MongoDB 8.0, if you try to run multiple concurrent compact commands on the same collection, MongoDB returns an error.
Geospatial Input Validation
Starting in MongoDB 8.0, you cannot use geospatial queries with malformed input. In prior versions, certain geospatial queries accept malformed input without an error.
OIDC Identity Providers Can Share an Issuer
Starting in MongoDB 8.0, when multiple identity providers (IDP) are defined, the oidcIdentityProviders parameter accepts duplicate issuer values as long as the audience value is unique for each issuer. This is also available in versions 7.3 and 7.0.
Removed Parameters
MongoDB 8.0 removes the storeFindAndModifyImagesInSideCollection parameter.
serverStatus Output Change
Starting in MongoDB 8.0, wiredTiger.concurrentTransactions is renamed to queues.execution.
Time Series system.buckets Collections
When you upgrade to 8.3, if you have any system.buckets collections that are not time-series collections, you might need to drop or rename those collections before you upgrade, depending on your 8.0 patch release:
- MongoDB 8.0.5 and later
- You do not need to drop
system.bucketscollections that aren't time-series collections before you upgrade. However, you must drop or rename them after you complete your upgrade. - MongoDB 8.0.4 and earlier
- You must drop or rename
system.bucketscollections that aren't time-series collections before you upgrade. Allsystem.bucketscollections must have valid time series options configured before you upgrade to versions 8.0.0 - 8.0.4.
To determine whether you have system.buckets collections that are not time-series collections, use the db.getCollectionInfos() method with a filter:
db.getCollectionInfos(
{
$and: [
{ name: { $regex: /^system\.buckets/ } },
{ 'options.timeseries': { $exists: false } }
]
}
)Sorting by Non-Existent Fields
When sorting by a nonexistent field, MongoDB does not guarantee any particular output ordering. The behavior in these cases may change from version to version.
Aggregation
$rank and $denseRank Behavior
Starting in MongoDB 8.0, null and missing field values in $denseRank and $rank sortBy operations are treated the same when calculating rankings. This change makes the behavior of denseRank and rank consistent with $sort.
$shardedDataDistribution Output
Starting in MongoDB 8.0, $shardedDataDistribution only returns output for a collection's primary shard if the primary shard has chunks or orphaned documents.
For details, see $shardedDataDistribution.
Upgraded TCMalloc
Starting in MongoDB 8.0, MongoDB uses an upgraded version of TCMalloc that uses per-CPU caches, instead of per-thread caches, to reduce memory fragmentation and make your database more resilient to high-stress workloads.
To use the new TCMalloc with better performance, see TCMalloc Performance Optimization for a Self-Managed Deployment.
tcmallocReleaseRate Parameter
Starting in MongoDB 8.0, tcmallocReleaseRate specifies the TCMalloc release rate in bytes per second, and the default value of tcmallocReleaseRate is reduced to 0.
In earlier versions, MongoDB used an older version of tcmalloc that:
- Set the default
tcmallocReleaseRateto1. - Accepted values for
tcmallocReleaseRatebetween0and10, inclusive.