MongoDB 6.0与7.0的CRUD命令语法无变化，差异源于底层机制：7.0自动碎片整理、哈希分片键索引可删（需满足条件）、驱动默认开启retryReads，而mongosh不支持重试。
CRUD 操作本身在 MongoDB 6.0 和 7.0 之间没有语法或行为层面的 breaking change —— 你写的 db.collection.insertOne()、db.collection.find() 这些命令，在两个版本里完全一样，也不需要改。
为什么你可能觉得“有差异”？
实际影响 CRUD 的，不是命令本身，而是底层机制和配套功能的演进。用户常遇到的“不一样”，基本来自三类场景：
- 分片集群上写入性能变化（尤其高并发插入）
- 驱动程序默认行为调整（比如重试逻辑）
- 索引与分片键管理方式变更（间接影响 CRUD 延迟）
分片集合的碎片整理：6.0 需手动，7.0 基本不用管
MongoDB 6.0 中，大量数据块迁移后容易产生碎片，导致 find()、updateMany() 等操作变慢；你得主动运行 sh.adminCommand({ defragmentCollection: "db.coll" }) 来合并小 chunk。
MongoDB 7.0 起，WiredTiger 引擎自动合并小数据段，defragmentCollection 命令仍存在但效果极弱，官方明确说“通常不需要执行”。如果你还在 7.0 上跑这个命令，不仅没收益，还可能触发元数据锁、拖慢 deleteMany()。
哈希分片键索引删除：7.0.3+ 才支持，且有条件
在 6.0 中，哈希分片键索引（如 {"shardKey": "hashed"}）是强制存在的，无法删 —— 所有 insertOne()、updateOne() 都要维护它，写入压力大时会成瓶颈。
7.0.3+ 允许用 db.collection.dropIndex("shardKey_hashed_1") 删除它，但必须满足：
- 先停平衡器：
sh.stopBalancer() - 确认无孤立文档：
db.aggregate([{$shardedDataDistribution: {}}])中每个 shard 的"numOrphanedDocs"为 0 - 存在另一个非哈希的分片键支撑索引（否则后续 add/remove shard 会失败）
删掉后，insertMany() 吞吐量明显上升，但代价是失去自动再平衡能力 —— 这不是“CRUD 命令变了”，而是你对集合结构的取舍变了。
驱动层重试行为：6.0 默认关，7.0 默认开（但 mongosh 不生效）
CRUD 方法如 collection.find()、collection.countDocuments() 在驱动中是否自动重试，取决于连接字符串参数和驱动版本：
- MongoDB 6.0 驱动需显式加
retryReads=true才启用可重试读 - 7.0 驱动默认开启
retryReads=true，遇到短暂网络抖动或副本集主节点切换时，find()可能重发一次 -
mongosh shell 完全不支持可重试读 —— 你在 shell 里执行
db.coll.find()失败就是失败，不会重试
这意味着：同一套应用代码，在 6.0 升到 7.0 后，find() 延迟毛刺可能减少，但日志里出现的“重试”记录会变多 —— 实际业务逻辑没变，只是容错路径更宽了。
真正要注意的，从来不是 insertOne() 写法有没有变，而是你是否意识到：7.0 的分片自动合并、哈希索引可删、驱动默认重试，这些“隐形开关”正在悄悄改变你 CRUD 操作的真实耗时和稳定性边界。
