不能照搬关系模型，因MongoDB依赖嵌套或引用组织数据而非JOIN；照搬会导致高并发下多次查找、冗余更新、ObjectId索引失效等性能断崖。
直接回答：不是“把表一比一转成集合”，而是根据查询路径、写入频率和数据生命周期，决定哪些字段该嵌套、哪些该拆分、哪些该引用——模型设计错了，后续所有迁移都白搭。
为什么不能照搬关系模型？
关系数据库靠 JOIN 拆解数据，MongoDB 靠嵌套或引用组织数据。如果把 MySQL 的 users 表和 orders 表原样变成两个 MongoDB 集合，再靠应用层模拟 JOIN，性能会断崖式下跌，尤其在高并发读场景下。
常见错误现象包括：
- 单次订单详情查询触发 5+ 次集合间查找（
find+aggregate+$lookup） - 更新用户地址时，要同步改 20 张关联集合里的冗余字段
- 导出的
ObjectId在目标库被当成字符串，导致索引失效
怎么判断字段该嵌套还是该引用？
核心看三点：读写比例、数据变更频率、是否跨业务域共享。
- 读多写少、生命周期一致、体积小（user.profile、
order.items - 写频繁、需独立更新、被多个集合复用 → 单独集合 +
$lookup或应用层 ID 关联。例如：products、regions - 动态字段（如用户自定义标签）、不定长数组（如日志条目）→ 存为
Array或Object，但必须加index或预设maxItems
注意：MongoDB 不支持跨集合事务回滚，所以嵌套结构一旦写入，就无法原子性地部分更新。比如订单里含支付信息，又含物流信息，若两者更新节奏不同，强行塞进一个文档，反而增加冲突概率。
Relational Migrator 的推荐模型怎么用？
它生成的初始映射只是起点，不是最终方案。工具默认倾向 1:1 映射（一张表 → 一个集合），但实际要人工干预三处：
- 在 schema visualizer 中拖拽合并表：把
orders和order_items拖到一起，勾选 “Embed as array” - 手动编辑字段类型：将 MySQL 的
DATETIME映射改为Date，而不是默认的String；把BIGINT对应到NumberLong或Int64 - 删掉无业务意义的外键字段：比如
user_id在嵌套后就成了冗余字段，不删会导致写入体积膨胀、索引膨胀
特别容易被忽略的是：Relational Migrator 默认不处理 JSON 字段的内部结构。如果 MySQL 里有 metadata TEXT 存着 JSON，它不会自动解析成 BSON 对象——你得提前用 JSON.parse() 或 CAST 预处理，否则迁过去就是一堆字符串。
验证模型是否合理？
别等数据全导入再测。在 Compass 或 mongosh 里跑几条真实查询，重点看：
-
explain("executionStats")返回的nReturned和totalDocsExamined是否接近（差太多说明没走对索引） - 嵌套数组字段是否被高频用于
$elemMatch查询——如果是，必须在该字段上建multikey index - 是否存在超大文档（> 5MB）：这类文档在 WiredTiger 中压缩效率低，且网络传输易超时
最常被跳过的动作是：没在迁移前确认目标集合的 writeConcern 和 readPreference 设置。比如用 w: "majority" 写入嵌套文档，但副本集延迟高，会导致迁移作业卡在“等待确认”状态，看起来像卡死。
