Server selection timeout是MongoDB驱动层错误，非MySQL问题；常见于混用MongoDB客户端或LB健康检查配置不当，需检查代码、配置及节点真实服务状态。
MySQL连接报 Server selection timeout 是驱动层问题，不是 MySQL 本身挂了
这个错误几乎总是出自 MongoDB 驱动（比如 pymongo、mongo-go-driver），不是 MySQL。MySQL 的典型超时错误是 Lost connection to MySQL server 或 Connection refused。如果你在查 MySQL 却看到 Server selection timeout，大概率是项目里混用了 MongoDB 客户端，或者日志/监控系统误标了服务名。
确认方法很简单：grep 代码库里的 mongodb://、MongoClient、pymongo；检查应用启动时加载的配置文件是否包含 spring.data.mongodb（Spring Boot）或 MONGODB_URI 环境变量。
负载均衡器（如 Nginx / HAProxy）转发 MongoDB 流量时，健康检查必须用 TCP 层，不能只靠 HTTP
MongoDB Wire Protocol 是二进制协议，不走 HTTP。如果 LB 配置了基于 /health 的 HTTP 健康检查，而后端 MongoDB 实例没开 HTTP 接口（默认关闭），就会误判节点下线，导致驱动反复尝试连接“不可达”节点，最终触发 Server selection timeout。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- Nginx Stream 模块必须启用，用
tcp_check或health_check type=tcp - HAProxy 要设
option tcp-check，并用tcp-check send-binary发送最小有效 MongoDB OP_QUERY 包（或更简单：用tcp-check connect看端口是否可通） - 避免在 LB 上配置
httpchk GET /health—— 这对 mongod 无效，除非你额外部署了mongod --httpinterface（已弃用且不安全）
Server selection timeout 默认是 30 秒，但实际耗时可能远超这个值
驱动会按拓扑发现逻辑轮询所有已知节点，每个节点尝试建立连接前会先做一次 socket connect（受 OS connect_timeout 影响），再发 hello 命令。如果某个节点网络不通但 SYN 不被拒绝（比如防火墙丢包），OS 层 connect 可能卡满 75 秒（Linux 默认 net.ipv4.tcp_syn_retries=6 → 指数退避重试），驱动还没开始计时就卡住了。
- 调低驱动级超时：
serverSelectionTimeoutMS=5000（单位毫秒） - 同步设置 socket 超时：
connectTimeoutMS=3000、socketTimeoutMS=5000 - 禁用不必要的拓扑扫描：
directConnection=true（单节点）或显式指定hosts列表，避免驱动自动发现失败节点
真正要检查 MongoDB 节点存活，别只 ping 端口
端口通 ≠ mongod 可服务。常见陷阱包括：
- mongod 进程存活但
storage.lock卡死（如异常关机后未修复）→ 连接成功但 hello 命令无响应 - 副本集主节点选举中，
hello返回{ "isWritablePrimary" : false }，驱动会跳过该节点——若所有节点都处于 thisNodeIsNotThePrimary 状态，也会触发 selection timeout - 节点内存 OOM 后被 kernel 杀掉，但 systemd 未及时更新状态，
systemctl is-active mongodb仍显示 active
验证方式：在目标机器上执行 mongosh --eval "db.runCommand({hello: 1})" --host localhost:27017，看是否返回 "ok" : 1 且字段完整。比 telnet localhost 27017 有效得多。
