MongoDB 4.2 用纯 { "timestamp": 1 } 范围分片支撑高并发日志写入必然导致写热点，必须改用 { "service": 1, "timestamp": 1 } 等组合片键或哈希分片，并配套关闭写关注、禁用文档验证、配置 TTL 索引等措施。
直接说结论：MongoDB 4.2 用基于时间的范围分片（如 { "timestamp": 1 }）支撑高并发日志写入，**几乎必然导致写热点，不推荐**。真要按时间维度分片，必须配合离散字段做组合片键，否则新日志全打到同一个 shard 上，mongos 路由再均衡也没用。
为什么纯 { "timestamp": 1 } 范围分片在日志场景下会崩
日志写入天然具有强时间局部性——所有新文档的 timestamp 都是递增的。MongoDB 范围分片按片键值区间切 chunk，比如当前最大 chunk 是 [ISODate("2026-04-10T00:00:00Z"), ISODate("2026-04-11T00:00:00Z"))，所有新日志都落在这个区间里，全部路由到该 chunk 所在的 shard。结果就是：
- 单个 shard CPU、磁盘 I/O、网络带宽迅速打满
- 其他 shard 几乎空闲，集群资源严重浪费
- chunk 拆分跟不上写入速度，
moveChunk迁移反而加剧抖动 - 写入延迟从毫秒级飙升到百毫秒甚至秒级
真正可行的组合片键设计：{ "service": 1, "timestamp": 1 }
必须引入一个离散度高、写入均匀的字段作为前导片键，把时间戳“打散”。service（服务名）、host（主机名）、log_type（日志类型）都是好选择，前提是它们取值足够多且分布均匀：
- 执行分片命令时需确保该字段已建索引：
db.logs.createIndex({ "service": 1, "timestamp": 1 }) - 启用分片：
sh.shardCollection("logging.logs", { "service": 1, "timestamp": 1 }) - 效果：相同
service的日志按时间有序，不同service的日志天然分散到不同 chunk，写入压力被均摊到多个 shard - 查询仍可高效利用索引：查某服务某时间段日志，
find({ "service": "api-gateway", "timestamp": { "$gte": ..., "$lt": ... } })走索引前缀
哈希分片能彻底避免热点，但代价是放弃时间范围查询
如果业务几乎不查“过去一小时所有日志”，只查“某个 traceId 或 service 的全部日志”，那 { "timestamp": "hashed" } 是最省心的方案：
- 写入绝对均匀：
sh.shardCollection("logging.logs", { "timestamp": "hashed" }) - 无需预估
service取值分布，也不怕某个服务突然爆发流量 - 但查
timestamp范围会触发全分片扫描，explain()显示"executionStats.nShards" == 所有 shard 数量 - 若必须支持时间范围查询，只能靠应用层聚合或额外建时间分区集合（如按天分库
logs_20260410）
配套必须做的几件事，否则分片形同虚设
光选对片键远远不够，以下配置漏掉任何一项，高并发写入照样卡死：
- 关闭写关注冗余校验：
insertMany(..., { writeConcern: { w: 1 } })，日志场景不要求强一致性 - 禁用文档验证：
db.createCollection("logs", { validator: {} })，避免 schema 校验拖慢吞吐 - 使用
WiredTiger引擎并调大 cache：--wiredTigerCacheSizeGB 4，防止频繁刷盘 - 日志集合必须设 TTL 索引：
db.logs.createIndex({ "expireAt": 1 }, { expireAfterSeconds: 0 })，让后台自动清理，别等磁盘爆 - 禁止用
ObjectId当主键存日志——它的前 4 字节是秒级时间戳，本身就会造成写热点
最容易被忽略的是：分片后 db.currentOp() 和 profiling 日志依然只在单个 mongod 上可见，跨分片操作审计必须靠自己收日志到独立集合，且那个集合本身也得用合理片键——否则你刚解决日志写入瓶颈，又造出一个新的监控写入瓶颈。
