数据库分析器输出
数据库分析器捕获有关读写操作、游标操作和数据库命令的数据信息。要配置数据库配置文件并设置捕获配置文件数据的阈值，请参阅数据库分析器部分。
数据库分析器会在 system.profile 集合中写入数据，这是一个固定大小集合。要查看分析器的输出，请对 system.profile 集合使用一般 MongoDB 查询。
注意
由于数据库分析器会将数据写入数据库中的system.profilecollection，因此分析器将分析某些写入活动，即使对于只读的数据库也是如此。
currentOp和数据库分析器会为所有 CRUD 操作报告相同的基本诊断信息，其中包括：
getMore（OP_GET_MORE 和command）
这些操作也包含在慢查询的日志中。有关慢查询日志的更多信息，请参阅 slowOpThresholdMs。
现在已无法在事务中对 system.profile 集合执行任何操作，包括读取操作。
警告
请勿尝试创建名称为system.profile的时间序列集合或视图，否则 MongoDB Server 会崩溃。
示例 system.profile 文档
下面介绍了在system.profilecollection中找到的一些文档，这些文档用于独立运行的实例：
system.profile中的以下文档反映了查找操作：
{ "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" }
update （和 delete）操作的分析器条目包含整个 update 命令。
以下示例反映了对名为report的集合执行的update操作。
{ "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" }
输出参考
对于任何单个操作，数据库分析器创建的文档都将包含以下字段的子集。这些文档中字段的精确选择取决于操作类型。
对于慢速操作，分析器条目和诊断日志消息包括storage信息。
注意
有关 MongoDB 版本的特定输出，请参阅相应版本的 MongoDB 手册。
system.profile.command包含与此操作相关的完整命令对象的文档。
例如，以下输出包含在
test数据库中items集合上执行的find操作的命令对象："command" : { "find" : "items", "filter" : { "sku" : 1403978 }, ... "$db" : "test" } 以下示例输出包含
getMore操作的命令对象，该命令对象由游标 ID 为19234103609的命令在名为test的数据库中名为items的集合上生成："command" : { "getMore" : NumberLong("19234103609"), "collection" : "items", "batchSize" : 10, ... "$db" : "test" }, 如果命令文档的大小超过 50 KB，则文档的格式如下：
"command" : { "$truncated": <string>, "comment": <string> } $truncated字段包含文档的字符串概要，不包括文档的comment字段（如果存在）。如果概要仍然超过 50 KB，则会进一步截断，在字符串末尾用省略号 (...) 表示。如果将注释传递给操作，则会出现
comment字段。任何数据库命令都可以附加注释。
system.profile.originatingCommand3.6 版本中的更改。
对于会从游标检索下一批结果的
"getmore"操作，originatingCommand字段包含最初创建该游标的完整命令对象（例如，find或aggregate）。
system.profile.keysExamined在 3.2.0 版本中进行了更改。
由
system.profile.nscanned重命名。 MongoDB 为执行操作而扫描的索引键数量。通常，如果
keysExamined远高于nreturned，则数据库正在扫描许多索引键以查找结果文档。考虑创建或调整索引，以提高查询性能。已在 3.4 版本中更改。
keysExamined可用于以下命令和操作：
system.profile.docsExamined在 3.2.0 版本中进行了更改： 由
system.profile.nscannedObjects重命名。MongoDB 为了执行该操作而扫描的集合中的文档数量。
已在 3.4 版本中更改。
docsExamined可用于以下命令和操作：
system.profile.hasSortStage在 3.2.0 版本中进行了更改： 由
system.profile.scanAndOrder重命名。hasSortStage是一个布尔值，当查询无法使用索引中的排序返回请求的排序结果时，此值为true；即MongoDB 接收到游标中包含的文档后必须对文档进行排序。此字段仅在值为true时出现。已在 3.4 版本中更改。
hasSortStage可用于以下命令和操作：getMore（OP_GET_MORE 和command）
system.profile.usedDisk4.2 版本中的新增功能。
一个布尔值，表示是否有任何聚合阶段由于内存限制而将数据写入临时文件。
仅在
usedDisk为 true 时显示。
system.profile.replanned3.2.5版本新增。
一个布尔值，表示查询系统是否逐出了缓存的计划并重新评估了所有候选计划。
仅在值为
true时显示。
system.profile.replanReason一个字符串，表示缓存计划被逐出的具体原因。
仅在
replanned的值为true时显示。
system.profile.keysDeleted已在 3.4 中删除。
更新在操作中更改的索引键的数量。 更改索引键的性能成本很小，因为数据库必须删除旧键并将新键插入 B-Tree 索引。
system.profile.writeConflicts写入操作过程中遇到的冲突次数；例如，一个
update操作尝试与另一个update操作修改同一文档。另请参阅写冲突。
system.profile.numYield该操作让出以允许其他操作完成的次数。通常，当操作需要访问 MongoDB 尚未完全读入内存的数据时，它们就会让出。这使得在 MongoDB 读取让出操作的数据时，其他已经在内存中有数据的操作可以完成。有关更多信息，请参阅有关操作让出时的常见问题解答。
system.profile.queryHash一个十六进制字符串，表示查询结构的哈希值，并且仅依赖于查询结构。
queryHash可以帮助识别具有相同查询结构的慢查询（包括写入操作的查询筛选器）。注意
与任何哈希函数一样，两个不同的查询结构可能会产生相同的哈希值。但是，不同查询结构之间不太可能发生哈希冲突。
有关
queryHash和planCacheKey的更多信息，请参阅queryHash和planCacheKey。4.2 版本中的新增功能。
system.profile.planCacheKey与此查询关联的计划缓存条目的键的哈希值。
与
queryHash不同，planCacheKey是查询结构和该结构当前可用索引的函数。换言之，如果添加/删除可以支持该查询结构的索引，则planCacheKey值可能会更改，而queryHash值不会更改。有关
queryHash和planCacheKey的更多信息，请参阅queryHash和planCacheKey。4.2 版本中的新增功能。
system.profile.lockssystem.profile.locks会提供操作过程中各种锁类型和锁模式的信息。可能的锁类型包括：
锁类型说明ParallelBatchWriterMode代表并行批量写入模式的锁。
在早期版本中，PBWM 信息作为
Global锁信息的一部分进行报告。ReplicationStateTransition表示副本集节点状态转换采用的锁。
Global代表全局锁定。
Database代表数据库锁。
Collection代表集合锁。
Mutex代表互斥锁。
Metadata代表元数据锁。
oplog表示 oplog 上的锁。
锁类型的可能锁模式如下：
锁模式说明R代表共享（S）锁。
W代表独占 (X) 锁。
r代表意向共享（IS）锁。
w代表意图独占 (IX) 锁。
针对各种锁类型返回的锁信息包括：
system.profile.locks.acquireWaitCount该操作因锁处于冲突模式而不得不等待
acquireCount锁获取的次数。acquireWaitCount小于或等于acquireCount。
system.profile.locks.timeAcquiringMicros操作获取锁所需等待的累计时间（以微秒为单位）。
timeAcquiringMicros除以acquireWaitCount得出特定锁模式的大致平均等待时间。
有关锁模式的更多信息，请参阅MongoDB 使用哪种类型的锁？
system.profile.authorization5.0.0 版本新增。
每次操作访问用户缓存的次数。只有当操作至少访问过一次用户缓存时，才会显示这些指标。
system.profile.authorization不包括在db.currentOp()输出中。
system.profile.storage版本 4.2 中的新增功能：（从 4.0.9 开始也可用）
system.profile.storage信息提供了存储引擎数据的指标和操作等待时间。仅当值大于零时，才会返回特定存储指标。
system.profile.storage.data.bytesRead版本 4.2 中的新增功能：（从 4.0.9 开始也可用）
该操作从磁盘读取到缓存的字节数。
从磁盘读入缓存的数据包括执行查询所需的所有内容。如果数据已在缓存中，则从磁盘读取的字节数可能为
0。从磁盘读取的字节数超过查询到的文档的字节数：
WiredTiger 以页面为单位读取，一页可能包含一份或多份文档。如果有文档位于某页面，则该页面中的所有文档都会读入缓存并包含在
bytesRead值中。如果缓存需要页面管理（例如，逐出或重新读取），则
bytesRead值包括在这些操作中从磁盘读取的数据。如果索引不在缓存中或者缓存中的索引已过时，WiredTiger 会从磁盘读取几个内部页和叶子页，以重建缓存中的索引。
system.profile.storage.data.bytesWritten版本 4.2 中的新增功能：（从 4.0.9 开始也可用）
操作从缓存写入磁盘的字节数。
WiredTiger 通常不需要将查询写入磁盘。查询修改的数据被写入内存缓存，WiredTiger 将其作为逐出或检查点操作的一部分刷新到磁盘。在这种情况下，
bytesWritten显示为 0。如果运行查询的线程需要强制页面管理（例如逐出），则 WiredTiger 会将页面内容写入磁盘。此刷新可能包含与查询本身所做的与更改无关的数据，这可能会导致
bytesWritten显示的值比预期更高。
system.profile.storage.timeWaitingMicros.cache版本 4.2 中的新增功能：（从 4.0.9 开始也可用）
该操作必须等待缓存中有空间的时间（以微秒为单位）。
system.profile.responseLength操作产生的结果文档的长度（以字节为单位）。过大的
responseLength会影响性能。要限制查询操作结果文档的大小，可以使用以下任何一种方法：注意
当 MongoDB 将查询配置文件信息写入日志时，
responseLength值位于名为reslen的字段中。
system.profile.protocolMongoDB 传输协议请求消息格式。
system.profile.millis从
mongod的角度来看，从操作开始到操作结束所用的时间（以毫秒为单位）。
system.profile.execStats包含查询操作的执行统计信息的文档。对于其他操作，该值为空文档。
system.profile.execStats以树的形式呈现统计信息；每个节点提供在查询操作阶段所执行操作的统计信息。注意
以下关于
execStats的字段列表并非详尽无遗，因为返回的字段因阶段而异。
system.profile.appName版本 3.4 中的新增功能。
运行操作的客户端应用程序的标识符。使用
appName连接字符串选项设置appName字段的自定义值。
system.profile.allUsers用于会话的经过身份验证的用户信息（用户名和数据库）的大量。 另请参阅自托管部署中的用户。