pymongo连接池状态需通过client._topology._servers各server._pool._available和_in_use等私有属性间接观察，推荐优先使用serverstatus命令获取服务端connections.current等指标；慢查询可通过commandstartedevent与commandsucceededevent配合手动计时实现，但应过滤心跳命令并控制监听粒度，且须结合explain和system.profile综合分析。
如何用 pymongo 获取连接池实时状态
PyMongo 的连接池状态不对外暴露完整指标，但可通过内部属性间接观察。关键看 client._topology._servers 和每个 server._pool 的统计字段。
实操建议：
- 启用
monitoring=True初始化客户端，配合自定义事件监听器捕获连接/请求生命周期 - 定期读取
client.options.pool_options.max_pool_size与client._topology._servers中各 server 的_pool._available、_pool._in_use值（注意：这些是私有属性，仅限调试，PyMongo 版本升级可能变动） - 避免轮询
_pool._size—— 它反映的是当前已创建的 socket 数，不是活跃连接数；真正有意义的是_in_use（正在被 cursor 或命令占用的连接数） - 若需稳定监控，推荐用
serverStatus命令查 MongoDB 服务端的connections.current和network.numRequests，比客户端侧更可靠
怎样让 PyMongo 记录慢查询（含执行时间与操作详情）
PyMongo 本身不提供“慢查询日志”开关，但可通过 CommandStartedEvent + 手动计时实现。重点不是记录所有查询，而是过滤出耗时超阈值的操作。
实操建议：
- 继承
command_logger = logging.getLogger("pymongo.command")并设为INFO级，可输出基础命令信息（不含耗时），但默认不打时间戳 - 更实用的做法：注册
CommandStartedEvent监听器，在事件触发时存event.connection_id和time.time()到字典；再在CommandSucceededEvent或CommandFailedEvent中取出起始时间，计算差值 - 注意过滤掉
ismaster、ping等心跳命令（检查event.command_name），否则日志会被噪音淹没 - 阈值建议从
100毫秒起步，写操作可放宽到500毫秒；记录内容至少包含：event.command_name、event.database_name、event.command.get("filter", {})、耗时（ms）
为什么 maxPoolSize 设得再大，慢查询也不减少？
连接池大小只解决“并发连接不够”的问题，而慢查询根源通常在查询设计、索引缺失或数据量突增，和连接数无关。盲目调高 maxPoolSize 反而可能加剧服务端压力。
实操建议：
- 先确认是否真有连接争抢：检查
client._topology._servers中各_pool._waiters是否持续 > 0；若为 0，说明没排队，瓶颈不在连接池 - 用
explain("executionStats")对慢操作逐条分析：关注nReturned与totalDocsExamined比值，若远小于 1，大概率缺索引 - 注意 PyMongo 的
find()默认不触发执行，真正耗时发生在第一次next()或list()调用时——日志埋点必须覆盖到迭代阶段，不能只盯find()调用本身 - 如果应用使用了
cursor.batch_size()，且 batch 过小（如 10），会导致大量往返，此时应优先调大 batch，而非加连接数
生产环境该不该开启 PyMongo 的命令监听？
能开，但必须控制粒度。全量监听 CommandStartedEvent 在高 QPS 场景下会带来明显性能损耗（每次命令多一次字典写入+时间戳获取）。
实操建议：
- 只监听
CommandSucceededEvent和CommandFailedEvent，跳过Started（省去一半事件）；失败事件本身就有诊断价值，成功事件则按需采样（例如每 100 次记录 1 次） - 用线程安全的 ring buffer（如
collections.deque(maxlen=1000)）暂存最近慢查询，避免日志 I/O 阻塞主线程 - 绝对不要在监听器里做阻塞操作（如写文件、发 HTTP 请求）；应只做轻量记录，由后台线程异步刷出
- MongoDB 服务端的
slowOpThresholdMs参数（默认 100ms）和system.profile集合仍是更权威的慢查询来源，PyMongo 日志只是辅助定位客户端行为
连接池状态要看服务端指标，慢查询要结合客户端监听与服务端 profile，两者不能互相替代。最容易被忽略的是：PyMongo 的“慢”，往往不是它慢，而是你让它反复执行了本可缓存或合并的操作。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
