MongoDB 的文档模型灵活，同一个集合中的文档结构可以完全不同。这种灵活性在开发阶段很方便，但迁移到关系型数据库时，就需要把灵活的文档结构拆成规整的表结构。
这不是简单的「一对一翻译」，而是需要重新思考数据建模方式。
第一步：分析文档结构
迁移前先对每个集合做结构分析：
这些信息决定了表结构设计的复杂度。
第二步：处理嵌套结构
这是最核心的设计决策。MongoDB 的嵌套文档在关系型数据库中有三种处理方式：
方式一：展开为列
适合嵌套层级浅（1-2层）、字段固定的结构。比如文档中的 address 对象有 city、province、street 三个字段，直接展开为 user 表的 city、province、street 三列。
优点： 查询简单，不需要 JOIN。缺点： 如果嵌套结构有变化，表结构也需要跟着改。
方式二：拆为关联表
适合嵌套结构复杂、有独立查询需求的场景。比如订单文档中的 items 数组，每个 item 有商品ID、数量、单价等字段，拆为 order_items 表更合理。
优点： 符合关系型数据库的建模习惯，便于独立查询和索引。缺点： 查询需要 JOIN，写入需要处理外键关系。
方式三：JSON 字段保留
适合结构不固定、查询需求少的场景。把整个嵌套结构存为 JSON 类型字段。
优点： 迁移简单，保留灵活性。缺点： JSON 字段内的数据无法建立常规索引，查询性能受限。部分数据库支持 JSON 字段的路径索引，但功能有限。
第三步：处理数组字段
MongoDB 的数组在关系型数据库中没有直接对应。
第四步：处理 Schema 灵活性
MongoDB 允许同一集合内文档结构不同，关系型数据库不允许。
实际建议
TiDB 在 MongoDB 文档模型迁移中的对应能力
TiDB 兼容 MySQL 协议，支持 JSON 类型和 JSON 路径索引（Multi-Valued Index），对于迁移过渡期保留灵活性的方案有较好的支持。TiDB 同时支持在线 DDL，迁移后如果需要调整表结构（比如把 JSON 列拆为关联表），可以在不中断业务的情况下完成。建议先对高频集合做查询模式分析，确定哪些嵌套结构需要拆表、哪些可以用 JSON 列过渡。
如果你正在规划 MongoDB 到关系型数据库的迁移，建议先从查询模式分析入手，围绕核心业务查询设计表结构，再逐步规范化。