单条insertOne变慢八成因WriteConcern被意外调高：默认w:1仅主节点内存写入即返（1–5ms），若设为w:"majority"或j:true，则需等待多数节点journal刷盘，延迟飙升至几十至数百毫秒，尤其在副本集节点响应不均、网络抖动或节点失联时，wtimeout未配或过大将导致操作卡满超时才报错。
单条插入变慢，八成是 WriteConcern 被意外调高了，不是数据库坏了，也不是磁盘扛不住。
为什么 insertOne 突然卡住 100ms+？
默认 w: 1 时，MongoDB 只等主节点内存写入就返回，通常在 1–5ms 内完成。一旦被设成 w: "majority" 或 j: true，就得等多数节点落盘或 journal 刷写，延迟直接跳到几十甚至几百毫秒——尤其副本集节点响应不均、网络抖动或某节点短暂失联时，wtimeout 未配或设得过大，就会卡满超时时间才报错。
-
w: "majority"在 3 节点副本集中实际要等 2 个节点确认；若其中 1 个延迟高或不可达，整个操作挂起 -
j: true强制 journal 持久化，SSD 上约增 5–15ms，HDD 上可能翻倍 - 驱动层全局设置了
writeConcern（比如 Spring Data MongoDB 的mongoTemplate.setWriteConcern(...)），但业务代码没意识到它覆盖了所有单条操作 - 连接池复用时，某个 session 或 client 实例被上游中间件/框架悄悄改过 writeConcern，后续请求全继承
怎么快速定位是不是 writeConcern 搞的鬼？
别先看 mongostat 或 mongotop——它们只告诉你“写慢”，不告诉你“为什么慢”。直接查当前连接的实际写入配置：
- 用
db.runCommand({ getLastError: 1 })查最后一次写操作的确认状态（注意：仅对上一条生效，需在同连接中紧接写操作后执行） - 在应用端打日志：Node.js 驱动可读
client.options.writeConcern；Java 驱动可查MongoClientOptions.getWriteConcern() - 检查是否误用了事务：即使只插一条，如果包在
session.startTransaction()里，commitTransaction的writeConcern才生效，且事务内所有操作强制w: 1，但提交阶段仍受你设的w: "majority"拖累 - 排查 ORM 或 SDK 封装：Spring Data MongoDB 的
@Document或 repository 方法若加了@WriteConcern注解，会覆盖默认行为
w: 1 和 w: "majority" 的真实代价差异
这不是“安全 vs 不安全”的抽象选择，而是具体到毫秒级的延迟账：
- 单节点 standalone 模式下，
w: "majority"等价于w: 1，无额外开销；但只要启用了副本集，它就立刻生效 -
w: 1+j: false（默认）：主节点写入内存即返，最快，但断电可能丢最近几秒数据 -
w: 1+j: true：主节点 journal 刷盘后返，比j: false多 5–20ms，但能扛住意外宕机 -
w: "majority"+j: false：多数节点内存写入即返，网络好时约 10–30ms；一旦有节点延迟，wtimeout成为瓶颈 -
w: "majority"+j: true：多数节点 journal 刷盘才返，生产环境常见 50–200ms 延迟，且wtimeout必须显式设（如5000），否则默认 60 秒
真正容易被忽略的是：wtimeout 只对 w > 1 或 w: "majority" 生效；设了 w: 1 却配 wtimeout，完全没用。
