图中先限定采集范围，再解释记录字段，分析器输出是诊断线索而非自动结论。
数据库变慢，打开 profiler 能不能立刻知道该加哪个索引？不一定。分析器能记录操作的相关执行信息，但记录范围受配置影响，字段也需要结合查询与执行计划理解。先问它采了什么、没采什么，再讨论某条慢操作意味着什么。
分析器记录的是操作信息
MongoDB 的数据库分析器可以把操作的耗时与执行相关信息写入 system.profile，供后续查询分析。它不是把每个客户端动作、每段网络传输和全部应用逻辑都完整录下来的端到端追踪系统。
比如应用等待连接池、客户端网络延迟和服务端执行，可能共同组成用户感受到的耗时。profiler 中的某个服务端字段，只对应其定义范围，不能直接替代整个请求的用户侧计时。比较前要确认起点、终点和采集对象。
采集还与目标节点、数据库及部署方式有关。mongos 的诊断日志与 mongod 上的数据库 profiler，不是任意互换的同一功能；没有在正确位置启用，就不能据此判断相关操作从未发生。
级别、阈值、采样和过滤各有含义
常见级别包括关闭、按慢操作等条件收集，以及收集所有操作。较宽的采集范围能提供更多材料，也会增加相应开销。不能把“多采一点”当作没有代价的默认诊断策略。
慢阈值描述达到什么条件值得记录，采样则控制符合相关条件的操作保留比例。设置过滤条件之后，阈值与采样参数还可能不再按原来的方式参与判断，具体应按当前配置核对。最高采集级别也不能简单按低级别过滤逻辑推导。
所以，一段时间里没有发现某类记录，可能是操作没发生，也可能是没达到阈值、未被采样、过滤范围不包含它，或旧记录已经被覆盖。需要先检查可观测范围，才能解释“没有数据”。
先看操作，再看扫描与返回
可以结合命名空间、操作类型、耗时、扫描文档与索引键数量、返回数量等字段观察一次操作。字段是否存在以及确切语义与操作和版本相关，不能要求所有记录都有完全相同的结构。
扫描很多、返回很少，可以作为继续检查过滤选择性和执行计划的线索，但不证明唯一原因就是没有索引。索引存在但不适合条件、数据分布变化、排序或聚合处理，也可能影响访问工作量，需要进一步证据。
同样，某个等待或让出执行机会的计数变大，不应被直接翻译成一个确定的锁故障。先理解字段的统计对象，再与其他监控、日志和计划对照，避免把相关性写成根因。
时间相近不代表同一个请求
应用侧一条请求可能触发多个数据库操作，数据库里的一条记录也可能只是其中一步。要把两边连起来，需要合适的请求标识、时间范围和操作上下文，不能仅凭“都发生在这一秒”就认定因果关系。
长尾问题尤其需要保留分布和样本，而不是只看平均值。若采样策略偏向慢操作，这批记录本来就不是全流量的均匀样本，不能直接用它计算整个服务的平均延迟或成功率。
这与分析器有没有价值无关，而是样本选择决定了能回答什么问题。用于定位慢操作的材料，未必适合直接做业务流量统计。
存储和运行开销也要管理
system.profile 是有容量边界的集合，旧数据会随着容量使用被覆盖，不能当作无限期完整审计档案。若要保留诊断证据，应按实际策略在覆盖前保存必要信息，并处理记录中可能包含的查询内容。
开启分析会消耗处理与存储资源，低阈值或全量采集尤其需要考虑目标环境。可以明确诊断范围与时间窗口，记录启停及配置变化，再比较前后现象，而不是长期保持最宽范围却不知道自己增加了什么负担。
从线索走向结论
一条可复述的排查主线是：确认采集范围，定位具体操作，核对工作量与执行计划，再关联应用和系统证据。优化之后用同一口径验证，不能因为一条记录消失就宣布问题全部解决。
如果 profiler 只采慢操作的一部分样本，你会拿这些记录直接计算“所有请求的平均延迟”吗？还需要补充哪些数据，才能让这个结论成立？