连接池复用的是已鉴权的连接而非会话，鉴权发生在连接建立阶段且不可跳过；增大maxPoolSize不能避免鉴权，仅减少新建连接次数，而minPoolSize预热可缓解冷启动密集鉴权。
连接池复用已认证会话在 MongoDB 4.4 中基本无效 —— 鉴权发生在连接建立阶段，不是会话级复用，而是连接级重用。
为什么 maxPoolSize 调大不能加速鉴权
很多人误以为增大连接池就能“缓存登录状态”，实际并非如此。MongoDB 的 SCRAM-SHA-256（或 LDAP）鉴权是在 TCP 连接建立后、首次执行命令前完成的。每次从连接池获取连接时，该连接早已完成鉴权；但新连接仍需走完整鉴权流程。所以提升性能的关键不是“避免鉴权”，而是“减少新建连接”。
-
minPoolSize设为非零值（如10），可让应用启动时预热一批已鉴权连接，避免冷启动时大量并发触发密集鉴权 -
maxPoolSize过大（如 >500）反而可能压垮 MongoDB 的 auth cache，导致authCache内存争用，serverStatus中可见authCache.misses上升 - 连接复用本身不跳过鉴权步骤，但能避免重复握手 + SASL exchange 的网络往返开销
authMechanismProperties 对性能的实际影响
在使用 SCRAM-SHA-256 时，authMechanismProperties 中的 SERVICE_NAME 或 CANONICALIZE_HOST_NAME 若配置不当，会导致每次连接都触发 DNS 解析或 Kerberos TGS 请求，显著拖慢连接建立 —— 这常被误判为“鉴权慢”。
- 确保
CANONICALIZE_HOST_NAME=false（默认为true），除非你明确依赖 Kerberos 主机名归一化 - 若未使用 Kerberos，不要设置
SERVICE_NAME，否则驱动会尝试发起 GSSAPI 流程，超时后才 fallback 到 SCRAM，白白浪费 1–3 秒 - Node.js 驱动中，该配置需写在连接字符串参数里：
?authMechanismProperties=CANONICALIZE_HOST_NAME:false
连接池空闲连接是否保持鉴权状态
是的，但有前提：连接未被服务端主动关闭，且未超过 maxIdleTimeMS（默认 0，即永不清理）。MongoDB 不会在空闲连接上撤销鉴权上下文，只要连接还活着，其 auth context 就有效。
-
maxIdleTimeMS建议设为300000（5 分钟），避免连接长期空闲后被防火墙或 mongod 的net.maxIncomingConnections策略静默断开 - 注意
socketTimeoutMS和maxIdleTimeMS的区别：socketTimeoutMS控制单次读写超时，不影响连接存活；而maxIdleTimeMS才决定连接是否从池中驱逐 - 如果看到频繁
Connection refused或Socket closed，先检查maxIdleTimeMS是否小于服务端的net.idleTimeoutMS（4.4 默认 600000）
真正影响鉴权吞吐的隐藏瓶颈
在高并发场景下，鉴权性能瓶颈往往不在客户端，而在服务端的 authSchema 锁或 LDAP 后端延迟。MongoDB 4.4 的 authSchema 是全局读锁，所有新连接的鉴权请求串行排队。
- 可通过
db.serverStatus().metrics.authentication查看numFailed和timeMillis，确认是否出现排队延迟 - 若使用 LDAP，务必启用
ldapBindMethod=none（匿名绑定）或配置本地缓存（如ldapUserCache），否则每个连接都会触发一次 LDAP 查询 - 避免在生产环境使用
admin数据库以外的数据库做用户认证 —— 跨库鉴权会额外增加 namespace 解析开销
最容易被忽略的一点：MongoDB 4.4 不支持“连接级凭证复用”的 API，所谓“复用鉴权会话”本质上只是复用已通过鉴权的连接。这意味着，任何导致连接重建的操作（如网络抖动、maxIdleTimeMS 触发、mongos 故障转移）都会重新触发完整鉴权流程 —— 它不是 session token，没有 TTL 或 refresh 机制。
