不能“照搬”MySQL表结构到MongoDB，必须按业务读写特征重构为嵌套文档或引用关系；因MongoDB无外键和原生JOIN，强行1:1映射会导致跨集合查询激增、应用层拼装、性能崩坏，违背其文档为中心的设计初衷。
直接回答：不能“照搬”MySQL表结构到MongoDB，必须按业务读写特征重构为嵌套文档或引用关系。强行1:1建集合、字段一一对应，等于用MongoDB跑SQL逻辑，后续查询性能和扩展性会迅速崩坏。
为什么不能直接映射表结构
MySQL的users表和orders表靠外键关联，而MongoDB没有外键约束，也没有原生JOIN。如果把这两张表原样变成users和orders两个集合，每次查“用户+最近3个订单”就得发两次查询、在应用层拼装——这违背了MongoDB以文档为中心的设计初衷。
常见错误现象包括：
- 大量应用层循环查
find()再findOne()，QPS上不去 - 索引建在
orders.userId上却效果差，因为无法覆盖聚合查询 - 迁移后发现90%的查询都要跨集合，反而比MySQL更慢
如何设计合理的文档模型
核心判断依据是：这个数据被谁读、怎么读、更新频次如何。不是“能不能嵌”，而是“值不值得嵌”。
典型场景与建议：
- 用户资料 + 地址列表 → 嵌入
addresses数组，因为地址读多写少、体积小、强归属 - 文章 + 评论 → 视情况：高频实时评论用单独
comments集合+articleId引用；低频静态评论可嵌入comments数组（注意BSON 16MB上限） - 订单 + 订单项 → 几乎总是嵌入
items数组，因二者强事务一致性、查询必共现 - 用户 + 用户行为日志 → 必须分离，日志写入频繁、体量大，嵌入会导致主文档膨胀、更新锁竞争
参数差异提醒：_id字段默认是ObjectId，若MySQL用INT主键，需确认是否保留数字ID（影响排序、分片键选择）；时间字段统一转为ISODate而非字符串。
用Relational Migrator做可视化建模时要注意什么
官方工具Relational Migrator能自动生成文档模型草图，但它不会替你做业务判断。容易踩的坑有：
- 它默认把所有一对多关系都标为“嵌入”，但没考虑
items数组可能超1000条，导致单文档突破16MB限制 - 它生成的
schema.json里字段类型是推测的（比如把VARCHAR(255)全当string），但实际业务中“手机号”“邮箱”应加pattern校验 - 它不处理历史数据中的NULL值——MySQL的
NULL在MongoDB里得明确转成null还是删掉字段，否则影响$exists查询
建议导出模型后，手动在Compass里用sample命令抽样验证文档结构是否符合预期，别只信UI预览。
迁移前必须验证的三件事
很多团队卡在最后一步不是脚本写错，而是忽略了这三点：
- 检查MySQL中
TEXT字段是否含控制字符（如\x00），MongoDB插入会直接报BSONError: null bytes not allowed - 确认MySQL时区设置（
@@session.time_zone），否则DATETIME转ISODate后时间偏移8小时 - 对含
JSON类型的MySQL字段，不能直接json.loads()再存——要先用json.dumps(..., ensure_ascii=False)避免中文乱码
真正难的从来不是怎么把数据倒进去，而是怎么让每一条文档在新模型下，依然能被业务代码自然、高效地消费。模型定错，后面所有索引、分片、备份策略都得返工。
