On this page本页内容
The database profiler captures data information about read and write operations, cursor operations, and database commands. 数据库探查器捕获有关读写操作、游标操作和数据库命令的数据信息。To configure the database profile and set the thresholds for capturing profile data, see the Database Profiler section.要配置数据库配置文件并设置捕获配置文件数据的阈值，请参阅数据库配置文件部分。
The database profiler writes data in the 数据库探查器将数据写入system.profile collection, which is a capped collection. system.profile集合，这是一个封顶集合。To view the profiler's output, use normal MongoDB queries on the 要查看探查器的输出，请在system.profile collection.system.profile集合上使用普通MongoDB查询。
Because the database profiler writes data to the 由于数据库探查器将数据写入数据库中的system.profile collection in a database, the profiler will profile some write activity, even for databases that are otherwise read-only.system.profile集合，因此探查器将对某些写入活动进行探查，即使对于其他情况下为只读的数据库也是如此。
currentOp and the database profiler report the same basic diagnostic information for all CRUD operations, including the following:currentOp和数据库探查器为所有CRUD操作报告相同的基本诊断信息，包括：
aggregatecountdeletedistinctfind (OP_QUERY and command)findAndModifygetMore (OP_GET_MORE and command)insertmapReduceupdateThese operations are also included in the logging of slow queries (see 这些操作也包含在慢速查询的日志记录中（有关慢速查询日志记录的更多信息，请参阅slowOpThresholdMs for more information about slow query logging).slowOpThresholdMs）。
Starting in MongoDB 4.4, it is no longer possible to perform any operation, including reads, on the 从MongoDB 4.4开始，不再可能在事务中对system.profile collection from within a transaction.system.profile集合执行任何操作，包括读取。
system.profile Documentsystem.profile文档The following presents some sample documents found in the 以下显示了在system.profile collection for operations on a standalone:system.profile集合中找到的一些示例文档，用于单机操作：
The following document in the system.profile collection shows metrics for a sample query operation on the test.report collection:system.profile集合中的以下文档显示了test.report集合上的示例查询操作的度量：
{
"op" : "query",
"ns" : "test.report",
"command" : {
"find" : "report",
"filter" : { "a" : { "$lte" : 500 } },
"lsid" : {
"id" : UUID("5ccd5b81-b023-41f3-8959-bf99ed696ce9")
},
"$db" : "test"
},
"cursorid" : 33629063128,
"keysExamined" : 101,
"docsExamined" : 101,
"fromMultiPlanner" : true,
"numYield" : 2,
"nreturned" : 101,
"queryHash" : "811451DD",
"planCacheKey" : "759981BA",
"locks" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(3),
"w" : NumberLong(3)
}
},
"Database" : {
"acquireCount" : { "r" : NumberLong(3) },
"acquireWaitCount" : { "r" : NumberLong(1) },
"timeAcquiringMicros" : { "r" : NumberLong(69130694) }
},
"Collection" : {
"acquireCount" : { "r" : NumberLong(3) }
}
},
"storage" : {
"data" : {
"bytesRead" : NumberLong(14736),
"timeReadingMicros" : NumberLong(17)
}
},
"responseLength" : 1305014,
"protocol" : "op_msg",
"millis" : 69132,
"planSummary" : "IXSCAN { a: 1, _id: -1 }",
"execStats" : {
"stage" : "FETCH",
"nReturned" : 101,
"executionTimeMillisEstimate" : 0,
"works" : 101,
"advanced" : 101,
"needTime" : 0,
"needYield" : 0,
"saveState" : 3,
"restoreState" : 2,
"isEOF" : 0,
"docsExamined" : 101,
"alreadyHasObj" : 0,
"inputStage" : {
...
}
},
"ts" : ISODate("2019-01-14T16:57:33.450Z"),
"client" : "127.0.0.1",
"appName" : "MongoDB Shell",
"allUsers" : [
{
"user" : "someuser",
"db" : "admin"
}
],
"user" : "someuser@admin"
}The profile entry for update (and delete) operation contains the entire update command.update（和delete）操作的配置文件条目包含整个更新命令。
The following document in the system.profile collection shows metrics for a sample update operation on the test.report collection:system.profile集合中的以下文档显示了test.report集合上的示例更新操作的度量：
{
"op" : "update",
"ns" : "test.report",
"command" : {
"q" : { },
"u" : { "$rename" : { "a" : "b" } },
"multi" : true,
"upsert" : false
},
"keysExamined" : 0,
"docsExamined" : 25000,
"nMatched" : 25000,
"nModified" : 25000,
"keysInserted" : 25000,
"keysDeleted" : 25000000,
"numYield" : 6985,
"locks" : {
"Global" : {
"acquireCount" : { "r" : NumberLong(6986), "w" : NumberLong(13972) }
},
"Database" : {
"acquireCount" : { "w" : NumberLong(6986) },
"acquireWaitCount" : { "w" : NumberLong(1) },
"timeAcquiringMicros" : { "w" : NumberLong(60899375) }
},
"Collection" : {
"acquireCount" : { "w" : NumberLong(6986) }
},
"Mutex" : {
"acquireCount" : { "r" : NumberLong(25000) }
}
},
"storage" : {
"data" : {
"bytesRead" : NumberLong(126344060),
"bytesWritten" : NumberLong(281834762),
"timeReadingMicros" : NumberLong(94549),
"timeWritingMicros" : NumberLong(139361)
}
},
"millis" : 164687,
"planSummary" : "COLLSCAN",
"execStats" : {
"stage" : "UPDATE",
"nReturned" : 0,
"executionTimeMillisEstimate" : 103771,
"works" : 25003,
"advanced" : 0,
"needTime" : 25002,
"needYield" : 0,
"saveState" : 6985,
"restoreState" : 6985,
"isEOF" : 1,
"nMatched" : 25000,
"nWouldModify" : 25000,
"wouldInsert" : false,
"inputStage" : {
"stage" : "COLLSCAN",
"nReturned" : 25000,
"executionTimeMillisEstimate" : 0,
"works" : 25002,
"advanced" : 25000,
"needTime" : 1,
"needYield" : 0,
"saveState" : 31985,
"restoreState" : 31985,
"isEOF" : 1,
"direction" : "forward",
"docsExamined" : 25000
}
},
"ts" : ISODate("2019-01-14T23:33:01.806Z"),
"client" : "127.0.0.1",
"appName" : "MongoDB Shell",
"allUsers" : [
{
"user" : "someuser",
"db" : "admin"
}
],
"user" : "someuser@admin"
}For any single operation, the documents created by the database profiler will include a subset of the following fields. 对于任何单个操作，数据库探查器创建的文档将包括以下字段的子集。The precise selection of fields in these documents depends on the type of operation.这些文档中字段的精确选择取决于操作类型。
Starting in MongoDB 4.2 (and in 4.0.9), for slow operations, the profiler entries and diagnostic log messages include 从MongoDB 4.2（和4.0.9）开始，对于慢速操作，探查器条目和诊断日志消息包括storage information.storage信息。
For the output specific to the version of your MongoDB, refer to the appropriate version of the MongoDB Manual.有关特定于MongoDB版本的输出，请参阅相应版本的MongoDB手册。
system.profile.op The type of operation. The possible values are:操作类型。可能的值为：
commandcountdistinctgeoNeargetMoregroupinsertmapReducequeryremoveupdatesystem.profile.ns The namespace the operation targets. 操作目标的命名空间。Namespaces in MongoDB take the form of the database, followed by a dot (MongoDB中的名称空间采用数据库的形式，后面是点（.), followed by the name of the collection..），后面是集合的名称。
system.profile.command Changed in version 3.6.在版本3.6中更改。
A document containing the full command object associated with this operation.包含与此操作关联的完整命令对象的文档。
For example, the following output contains the command object for a 例如，以下输出包含对名为find operation on a collection named items in a database named test:test的数据库中名为items的集合执行find操作的命令对象：
"command" : { "find" : "items", "filter" : { "sku" : 1403978 }, ... "$db" : "test" }
The following example output contains the command object for a 下面的示例输出包含用于getMore operation generated by a command with cursor id 19234103609 on a collection named items in a database named test:getMore操作的命令对象，该操作由一个游标id为19234103609的命令在名为test的数据库中的一个名为items的集合上生成：
"command" : { "getMore" : NumberLong("19234103609"), "collection" : "items", "batchSize" : 10, ... "$db" : "test" },
If the command document exceeds 50 kilobytes, the document has the following form:如果命令文档超过50千字节，则文档的格式如下：
"command" : { "$truncated": <string>, "comment": <string> }
The $truncated field contains a string summary of the document excluding the document's comment field if present. $truncated字段包含文档的字符串摘要，不包括文档的注释字段（如果存在）。If the summary still exceeds 50 kilobytes then it is further truncated, denoted by an ellipsis (...) at the end of the string.如果摘要仍然超过50千字节，则它将被进一步截断，由字符串末尾的省略号（…）表示。
The 如果向操作传递了注释，则会出现comment field is present if a comment was passed to the operation. comment字段。Starting in MongoDB 4.4, a comment may be attached to any database command.从MongoDB 4.4开始，注释可以附加到任何数据库命令。
system.profile.originatingCommand Changed in version 3.6.在版本3.6中更改。
For 对于从游标检索下一批结果的"getmore" operations which retrieve the next batch of results from a cursor, the originatingCommand field contains the full command object (e.g. find or aggregate) which originally created that cursor."getmore"操作，originatingCommand字段包含最初创建该游标的完整命令对象（例如find或aggregate）。
system.profile.cursorid The ID of the cursor accessed by a query and getmore operations.query和getmore操作访问的游标的ID。
system.profile.keysExamined Changed in version 3.2.0.在版本3.2.0中更改。
Renamed from 从system.profile.nscanned. system.profile.nscanned重命名。The number of index keys that MongoDB scanned in order to carry out the operation.MongoDB为执行操作而扫描的索引键数。
In general, if 通常，如果keysExamined is much higher than nreturned, the database is scanning many index keys to find the result documents. keysExamined远高于nreturned，则数据库正在扫描许多索引键以查找结果文档。Consider creating or adjusting indexes to improve query performance..考虑创建或调整索引以提高查询性能。
Changed in version 3.4.在版本3.4中更改。
keysExamined is available for the following commands and operations:可用于以下命令和操作：
system.profile.docsExamined Changed in version 3.2.0.在版本3.2.0中更改。
system.profile.nscannedObjects.system.profile.nscannedObjects重命名。
The number of documents in the collection that MongoDB scanned in order to carry out the operation.MongoDB为执行操作而扫描的集合中的文档数。
Changed in version 3.4.在版本3.4中更改。
docsExamined is available for the following commands and operations:可用于以下命令和操作：
system.profile.hasSortStage Changed in version 3.2.0.在版本3.2.0中更改。
system.profile.scanAndOrder.system.profile.scanAndOrder重命名。
hasSortStage is a boolean that is 是一个布尔值，当查询无法使用索引中的排序返回所请求的排序结果时为true when a query cannot use the ordering in the index to return the requested sorted results; i.e. MongoDB must sort the documents after it receives the documents from a cursor. true；即，MongoDB必须在从游标接收到文档后对文档进行排序。The field only appears when the value is 该字段仅在值为true.true时显示。
Changed in version 3.4.在版本3.4中更改。
hasSortStage is available for the following commands and operations:可用于以下命令和操作：
find (OP_QUERY and command)getMore (OP_GET_MORE and command)findAndModifymapReduceaggregatesystem.profile.usedDisk New in version 4.2.在版本4.2中新增。
A boolean that indicates whether any aggregation stage wrote data to temporary files due to memory restrictions.一个布尔值，指示任何聚合阶段是否由于内存限制而将数据写入临时文件。
Only appears if 仅当usedDisk is true.usedDisk为true时显示。
system.profile.nMatched The number of documents that match the query condition for the update operation.与更新操作的查询条件匹配的文档数。
system.profile.upsert A boolean that indicates the update operation's 指示更新操作的upsert option value. upsert选项值的布尔值。Only appears if 仅当upsert is true.upsert为true时显示。
system.profile.fromMultiPlanner A boolean that indicates whether the query planner evaluated multiple plans before choosing the winning execution plan for the query.一个布尔值，指示查询计划器在为查询选择获胜执行计划之前是否评估了多个计划。
Only present when value is 仅在值为true.true时存在。
system.profile.replanned A boolean that indicates whether the query system evicted a cached plan and re-evaluated all candidate plans.一个布尔值，指示查询系统是否逐出缓存的计划并重新评估所有候选计划。
Only present when value is 仅在值为true.true时存在。
system.profile.replanReason New in version 4.4.在版本4.4中新增。
A string that indicates the specific reason a cached plan was evicted.一个字符串，指示收回缓存计划的特定原因。
Only present when value for 仅当replanned is true.replanned的值为true时出现。
system.profile.keysInserted The number of index keys inserted for a given write operation.为给定写入操作插入的索引键数。
system.profile.keysDeleted Removed in 3.4.在3.4中删除。
The number of index keys the update changed in the operation. 更新在操作中更改的索引键数。Changing an index key carries a small performance cost because the database must remove the old key and inserts a new key into the B-tree index.更改索引键会带来较小的性能成本，因为数据库必须删除旧键并将新键插入到B树索引中。
system.profile.writeConflicts The number of conflicts encountered during the write operation; e.g. an 写入操作期间遇到的冲突数；update operation attempts to modify the same document as another update operation. update操作试图修改与另一update操作相同的文档。See also write conflict.另请参阅写入冲突。
system.profile.numYield The number of times the operation yielded to allow other operations to complete. 操作允许其他操作完成的次数。Typically, operations yield when they need access to data that MongoDB has not yet fully read into memory. 通常情况下，当操作需要访问MongoDB尚未完全读入内存的数据时，它们会让步。This allows other operations that have data in memory to complete while MongoDB reads in data for the yielding operation. 这允许内存中有数据的其他操作在MongoDB读取数据以进行让步操作时完成。For more information, see the FAQ on when operations yield.有关更多信息，请参阅常见问题解答，了解操作何时产生。
system.profile.queryHash A hexadecimal string that represents a hash of the query shape and is dependent only on the query shape. 一个十六进制字符串，表示查询形状的哈希，仅依赖于查询形状。queryHash can help identify slow queries (including the query filter of write operations) with the same query shape.可以帮助识别具有相同查询形状的慢速查询（包括写操作的查询筛选器）。
As with any hash function, two different query shapes may result in the same hash value. 与任何哈希函数一样，两个不同的查询形状可能导致相同的哈希值。However, the occurrence of hash collisions between different query shapes is unlikely.但是，不同查询形状之间不太可能发生哈希冲突。
For more information on 有关queryHash and planCacheKey, see queryHash and planCacheKey.queryHash和planCacheKey的更多信息，请参阅queryHash和planCacheKey。
New in version 4.2.在版本4.2中新增。
system.profile.planCacheKey A hash of the key for the plan cache entry associated with the query.与查询关联的计划缓存项的密钥哈希。
Unlike the 与queryHash, the planCacheKey is a function of both the query shape and the currently available indexes for that shape. queryHash不同，planCacheKey是查询形状和该形状当前可用索引的函数。That is, if indexes that can support the query shape are added/dropped, the 也就是说，如果添加/删除了支持查询形状的索引，则planCacheKey value may change whereas the queryHash value would not change.planCacheKey值可能会更改，而queryHash值不会更改。
For more information on 有关queryHash and planCacheKey, see queryHash and planCacheKey.queryHash和planCacheKey的更多信息，请参阅queryHash和planCacheKey。
New in version 4.2.在版本4.2中新增。
system.profile.locks The system.profile.locks provides information for various lock types and lock modes held during the operation.system.profile.locks提供了操作期间保持的各种锁类型和锁模式的信息。
The possible lock types are:可能的锁类型有：
| Lock Type | |
|---|---|
ParallelBatchWriterMode |
|
ReplicationStateTransition |
|
Global | |
Database | |
Collection | |
Mutex | |
Metadata | |
oplog |
The possible locking modes for the lock types are as follows:锁定类型的可能锁定模式如下：
R | |
W | |
r | |
w |
The returned lock information for the various lock types include:返回的各种锁类型的锁信息包括：
system.profile.locks.acquireCount Number of times the operation acquired the lock in the specified mode.操作在指定模式下获取锁的次数。
system.profile.locks.acquireWaitCount Number of times the operation had to wait for the 由于锁处于冲突模式，操作必须等待acquireCount lock acquisitions because the locks were held in a conflicting mode. acquireCount锁获取的次数。acquireWaitCount is less than or equal to 小于或等于acquireCount.acquireCount。
system.profile.locks.timeAcquiringMicros Cumulative time in microseconds that the operation had to wait to acquire the locks.操作获取锁所需等待的累积时间（微秒）。
timeAcquiringMicros divided by acquireWaitCount gives an approximate average wait time for the particular lock mode.timeAcquiringMicros除以acquireWaitCount得到特定锁定模式的近似平均等待时间。
system.profile.locks.deadlockCount Number of times the operation encountered deadlocks while waiting for lock acquisitions.等待锁获取时操作遇到死锁的次数。
For more information on lock modes, see What type of locking does MongoDB use?.有关锁定模式的更多信息，请参阅MongoDB使用的锁定类型？。
system.profile.authorization New in version 5.0.0.在版本5.0.0中新增。
The number of times the user cache is accessed for each operation. 每次操作访问用户缓存的次数。These metrics are only displayed when an operation has accessed the user cache at least once.仅当操作访问用户缓存至少一次时，才会显示这些度量。
These metrics are only available when slow operation logging or database profiling is enabled.这些指标仅在启用慢速操作日志记录或数据库分析时可用。
system.profile.authorization is not included in 不包括在db.currentOp() output.db.currentOp()输出中。
system.profile.authorization.startedUserCacheAcquisitionAttempts The number of times the operation tried to access the user cache.操作尝试访问用户缓存的次数。
system.profile.storage New in version 4.2.在版本4.2中新增。 (Also available starting in 4.0.9也可从4.0.9开始提供)
The system.profile.storage information provides metrics on the storage engine data and wait time for the operation.system.profile.storage信息提供存储引擎数据和操作等待时间的度量。
Specific storage metrics are returned only if the values are greater than zero.仅当值大于零时，才会返回特定存储度量。
system.profile.storage.data.bytesRead New in version 4.2.在版本4.2中新增。 (Also available starting in 4.0.9也可从4.0.9开始提供)
Number of bytes read by the operation from the disk to the cache.操作从磁盘读取到缓存的字节数。
Data read from disk into the cache includes everything needed to execute the query. 从磁盘读取到缓存中的数据包括执行查询所需的所有内容。If the data is already in the cache, then the number of bytes read from disk could be 如果数据已在缓存中，则从磁盘读取的字节数可能为0.0。
The number of bytes read from disk includes more than the queried documents:从磁盘读取的字节数超过查询的文档：
bytesRead value.bytesRead值中。bytesRead value includes data read from disk in these operations.bytesRead值包括这些操作中从磁盘读取的数据。system.profile.storage.data.timeReadingMicros New in version 4.2.在版本4.2中新增。 (Also available starting in 4.0.9)
Time in microseconds that the operation had to spend to read from the disk.操作从磁盘读取所需的时间（微秒）。
system.profile.storage.data.bytesWritten New in version 4.2.在版本4.2中新增。 (Also available starting in 4.0.9也可从4.0.9开始提供)
Number of bytes written by the operation from the cache to the disk.操作从缓存写入磁盘的字节数。
WiredTiger typically doesn't require the query to write to disk. Data modified by the query is written to an in-memory cache that WiredTiger flushes to disk as part an eviction or checkpoint operation. WiredTiger通常不需要将查询写入磁盘。查询修改的数据写入内存缓存，WiredTiger将其作为逐出或检查点操作的一部分刷新到磁盘。In such cases, 在这种情况下，bytesWritten shows as 0.bytesWritten显示为0。
If the thread running the query requires forced page management (such as eviction), WiredTiger writes the page contents to disk. 如果运行查询的线程需要强制页面管理（如逐出），WiredTiger会将页面内容写入磁盘。This flush likely includes data unrelated to changes made by the query itself, which can cause 此刷新可能包括与查询本身所做更改无关的数据，这可能导致字节写入显示比预期更高的值。bytesWritten to show a higher value than expected.
system.profile.storage.data.timeWritingMicros New in version 4.2.在版本4.2中新增。 (Also available starting in 4.0.9也可从4.0.9开始提供)
Time in microseconds that the operation had to spend to write to the disk.操作写入磁盘所需的时间（微秒）。
system.profile.storage.timeWaitingMicros.cache New in version 4.2.在版本4.2中新增。 (Also available starting in 4.0.9也可从4.0.9开始提供)
Time in microseconds that the operation had to wait for space in the cache.操作必须等待缓存中的空间的时间（微秒）。
system.profile.responseLength The length in bytes of the operation's result document. 操作结果文档的字节长度。A large 较大的responseLength can affect performance. responseLength会影响性能。To limit the size of the result document for a query operation, you can use any of the following:要限制查询操作的结果文档的大小，可以使用以下任何一种方法：
When MongoDB writes query profile information to the log, the 当MongoDB将查询配置文件信息写入日志时，responseLength value is in a field named reslen.responseLength值位于名为reslen的字段中。
system.profile.protocol The MongoDB Wire Protocol request message format.MongoDB有线协议请求消息格式。
system.profile.millis The time in milliseconds from the perspective of the 从mongod from the beginning of the operation to the end of the operation.mongod的角度来看，从操作开始到操作结束的时间（毫秒）。
system.profile.execStats A document that contains the execution statistics of the query operation. 包含查询操作执行统计信息的文档。For other operations, the value is an empty document.对于其他操作，该值为空文档。
The system.profile.execStats presents the statistics as a tree; each node provides the statistics for the operation executed during that stage of the query operation.system.profile.execStats将统计数据显示为树；每个节点提供在查询操作的该阶段执行的操作的统计信息。
system.profile.client The IP address or hostname of the client connection where the operation originates.发起操作的客户端连接的IP地址或主机名。
system.profile.appName The identifier of the client application which ran the operation. 运行该操作的客户端应用程序的标识符。Use the 使用appName connection string option to set a custom value for the appName field.appName连接字符串选项为appName字段设置自定义值。