LDAP认证仅在连接建立时触发，延迟增高主因是短连接导致每次查询前重复LDAP bind；需检查连接池配置、LDAP查询模板、TLS握手及日志确认是否生效。
LDAP 集成本身不参与查询执行，延迟增高几乎肯定来自认证链路阻塞或配置错位，而不是 MongoDB 服务端变慢。
检查 mongod 是否在每次查询时都重走 LDAP 认证
默认情况下，MongoDB 使用 LDAP 进行用户身份验证（authMechanism=PLAIN 或 SCRAM-SHA-256 + LDAP 账户映射），但**认证只发生在连接建立时**。如果应用层使用短连接（如 PHP-FPM 每次请求新建连接）、或驱动未复用连接池，就会导致每条查询前都触发一次 LDAP bind —— 这才是延迟突增的主因。
- 用
mongostat观察conn列是否持续飙升，同时net/numRequests远高于实际 QPS，说明连接频繁重建 - 在 LDAP 服务端（如 OpenLDAP 或 Active Directory）查日志，确认是否存在大量
bind请求，时间戳是否与 MongoDB 查询延迟高峰完全重合 - PHP 客户端需显式启用连接池：
new Manager('mongodb://host/', ['minPoolSize' => 10, 'maxPoolSize' => 50])；Node.js 驱动则依赖maxPoolSize和minPoolSize配置
验证 LDAP 映射规则是否触发冗余查询
MongoDB 支持通过 ldapQueryTemplate 或 ldapUserToDNMapping 将用户名转为 DN，但如果模板中包含通配符（如 uid={0},ou=users,dc=example,dc=com）且未加索引，AD 可能执行 subtree search，耗时从毫秒级升至秒级。
- 在
mongod.conf中检查security.authorization.ldap.queryTemplate是否含模糊匹配（如(&(objectClass=user)(sAMAccountName={0}))是安全的；(cn=*{0}*)则危险 - 用
ldapsearch -x -H ldap://ad-server -D "bind-user" -W -b "dc=example,dc=com" "(&(objectClass=user)(sAMAccountName=testuser))"手动测单次查询耗时 - 确保 AD 中
sAMAccountName字段已建全局唯一索引（默认已有），避免 fallback 到慢扫描
确认 TLS 握手没成为瓶颈
若 LDAP 配置了 ldapTransportSecurity=TLS，而客户端证书校验开启、或 CA 证书链不完整，每次 bind 前的 TLS handshake 可能卡住 1–3 秒，尤其在高并发下积压明显。
- 用
openssl s_client -connect ad-server:636 -showcerts测 TLS 握手是否稳定在 100ms 内 - 检查
mongod日志是否出现LDAP bind failed: Can't contact LDAP server或SSL connect error类报错 - 生产环境建议关闭客户端证书校验（
sslAllowInvalidCertificates: true），仅靠服务器端证书保证传输加密——这比全链校验快一个数量级
绕过 LDAP 的临时诊断法
真正的问题往往藏在“集成后没改其他东西”这个假设里。最有效的排查是做最小变量隔离：停用 LDAP 认证，改用本地 SCRAM 用户，观察延迟是否归零。
- 临时注释
mongod.conf中整个security.authorization.ldap块，重启 mongod - 创建本地用户：
db.createUser({user:'test',pwd:'x',roles:['readWriteAnyDatabase']}) - 用该用户直连测试相同查询，对比
explain("executionStats")中的executionTimeMillis - 若延迟消失，问题 100% 在 LDAP 链路；若仍在，说明是 coincidental 的其他变更（如索引失效、分片不均、WiredTiger cache 溢出）
最容易被忽略的是：LDAP 配置修改后，mongod 不会自动 reload，必须重启进程才能生效；而运维常误以为改完 conf 就 OK，结果旧配置还在跑，且错误日志被 logLevel: 0 屏蔽掉。
