deleteMany 会自动路由到对应分片，但仅限查询条件包含分片键（等值或前缀匹配）；否则广播至所有分片。必须显式设置 writeConcern: { w: "majority" } 防数据不一致，大批量删除应优先考虑索引优化或直接 drop 集合。
分片集群里 deleteMany 会自动路由到对应分片吗
会，但仅限于查询条件中包含分片键。MongoDB 的 mongos 路由器能识别分片键字段（比如 pid、user_id），只要 filter 中明确使用该字段做等值或范围匹配，删除操作就会被精准下发到目标分片，不广播、不跨分片扫描。
常见翻车点：
- 条件里用了非分片键字段（如
{ status: "draft" }），mongos只能 fan-out 到所有分片执行，性能断崖式下跌 - 分片键是复合键（如
{ orgId: 1, _id: 1 }），但只传了{ orgId: 123 }—— 这属于“前缀匹配”，仍可路由；若传{ _id: ObjectId("...") }单独出现，则无法路由，退化为全分片扫描 - 用了
$regex或$text等无法下推的运算符，同样触发全分片执行
deleteMany 在分片集群里要不要加 writeConcern
要，而且必须设为 { w: "majority" }。分片集群中，一次 deleteMany 实际是多个独立的分片内删除操作，每个分片返回成功后，mongos 才汇总响应。默认 w: 1 只保证主分片写入，若某分片主节点在删除后立即宕机且未同步，数据可能“已删但恢复后又回来”。
实操建议：
- 线上环境一律显式传参：
db.collection.deleteMany({ pid: 123 }, { writeConcern: { w: "majority" } }) - 避免用
db.runCommand({ delete: ... })手动构造，它默认不继承 shell 或驱动的 writeConcern 配置 - 如果业务允许短暂不一致，且对吞吐敏感（如日志归档），可降级为
{ w: 1, j: true }，确保主分片落盘+写日志，但不等多数副本确认
大集合删几百万条，为什么 deleteMany 比 remove 快但还是慢
因为 remove() 已在 MongoDB 4.4+ 被标记废弃，5.0+ 完全移除；而 deleteMany() 是标准批量接口，支持事务、返回 deletedCount、能被复制集 oplog 正确记录——但它仍是“逻辑删除”：逐条标记文档为已删除、更新索引项、写 oplog 条目、触发后台空间回收。
真正卡顿的根源：
- 多索引场景下，每删一条文档，所有索引都要更新；8个索引 = 8倍 I/O 开销
- WiredTiger 引擎在大批量删除时频繁 checkpoint，导致 I/O 和 CPU 尖峰
- 若没建索引的删除字段（如按
createdAt删旧数据），会全表扫描，锁持有时间长，阻塞其他写入
提速关键：先确保 filter 字段有支撑索引，再用 hint 强制走索引（例如 { hint: { createdAt: 1 } }）。
什么情况下该放弃 deleteMany，直接 drop 分片集合
当你删的是整个月/整季度/整租户的数据，且这些数据已按分片键隔离进独立集合（如 logs_202501、tenant_abc_events），drop() 是唯一合理选择。
注意三个硬性前提：
- 该集合上没有 TTL 索引（
drop()后 TTL 不会自动重建） - Change Stream 消费端已处理
"invalidate"事件，否则流会中断卡死 - 你控制着集合命名规则，能 100% 确认要删的集合名（脚本里拼错一个字符就删错库）
最常被忽略的一点：drop() 后，原集合的 createDate 时间戳重置，某些依赖创建时间做自动归档或监控告警的工具会误判为“新集合上线”。
