分片集群中 write concern 延迟更高，是因为 mongos 必须等待所有涉及分片各自满足其副本集内的 majority（如 3 节点需 2 确认），且分片间不共享 oplog 进度、无法跨分片协调，最慢分片决定整体延迟。
分片集群里设高 write concern（比如 w: "majority"）不会自动变快，反而容易卡在某个慢分片上——因为 mongos 会等所有涉及分片都返回确认，而最慢的那个分片决定整体延迟。
为什么分片集群的 write concern 延迟比副本集更高？
根本原因是写关注在分片间是“取并集”而非“取交集”：每个分片独立执行自己的写关注逻辑，mongos 必须收齐所有分片的响应才向客户端返回成功。哪怕只有一个分片因网络抖动、磁盘 I/O 高或从节点落后而卡住，整个操作就会被 wtimeout 拖住或失败。
-
w: "majority"在分片集群中不是全局多数，而是每个分片各自计算其副本集内的多数（例如某分片是 3 节点副本集，则需 2 个节点确认） - 分片之间不共享 oplog 进度，
mongos无法做跨分片的写入协调或进度合并 - 如果某个分片只有 1 个有投票权节点（比如单节点分片），
w: "majority"实际退化为w: 1，但其他分片仍按自身多数等待，导致行为不一致
bulkWrite() 中显式传 writeConcern 的常见误用
很多人在 db.collection.bulkWrite() 里给每个操作单独加 writeConcern，这不仅没用，还会触发冗余校验和额外序列化开销。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
-
bulkWrite()只接受顶层writeConcern参数，内部各操作（如insertOne、updateOne）不能覆盖它 - 若同时在连接级（
db.getMongo().setWriteConcern()）和命令级都设了writeConcern，以命令级为准；但混用容易漏掉某个分片的实际生效值 - 对跨分片的批量操作，
wtimeout应设为单个分片最大预期延迟的 2–3 倍，而不是副本集场景下的固定 5000ms
如何安全降低 write concern 延迟而不丢数据？
关键不是盲目调低 w，而是让写关注更贴合业务语义。以下做法实测有效：
- 对非关键字段（如统计计数器、缓存标记），改用
{w: 1, j: false}—— 主节点落盘即返，避免等从节点 - 对强一致性要求的操作（如用户余额扣减），保留
{w: "majority", j: true}，但必须搭配wtimeout: 10000（10 秒），防止某分片临时不可用导致长阻塞 - 禁用全局默认写关注（
setDefaultRWConcern），改用显式传参。否则事务内写入可能意外继承过严的默认值，而事务本身只支持事务级 writeConcern，不认操作级 - 检查每个分片的副本集配置：确保所有分片都至少有 3 个投票节点（
members[n].votes > 0），避免单点分片拖垮整体"majority"计算
事务中 writeConcern 的唯一合法用法
多文档事务里，writeConcern 只能在 session.startTransaction() 时传入，不能在 insertOne() 或 updateOne() 里重复指定——否则驱动会静默忽略，且 mongos 日志里会出现 "write concern ignored in transaction" 警告。
- 正确写法：
session.startTransaction({writeConcern: {w: "majority", wtimeout: 15000}}) - 错误写法：
collection.updateOne({...}, {writeConcern: {...}})（事务内） - 事务的
wtimeout必须 ≥ 单个分片内最长可能的写入耗时，否则事务可能因超时被中止，已写入的分片也不会回滚
真正影响性能的从来不是 write concern 字面值，而是你有没有意识到：分片集群里，“多数”是 per-shard 的，而“慢”是传染性的。盯住每个分片的 rs.status() 和 sh.status() 输出里的同步延迟，比调参数更重要。
