将存量MySQL迁移至MongoDB并在DRF中使用的方案咨询

你原方案仅在极小数据量、无复杂字段/关联的测试场景下能跑通，放到大体量数据的生产环境直接落地有明显缺陷，不建议直接使用：

• 第一步依赖manage.py makemigrations/migrate初始化Mongo结构的问题：目前DRF生态对接MongoDB最常用的Djongo引擎，对复杂字段、嵌套结构、联合索引的迁移兼容度并不完美，自动生成的集合结构、索引经常和模型定义存在偏差，后续迭代模型时也容易出现迁移冲突、脏数据问题。
• 第二步导出CSV手动迁移的问题：CSV格式本身不保留字段类型信息，MySQL中的datetime、decimal、JSON、枚举类型导出后很容易统一转为字符串，导入Mongo时需要逐字段做类型转换，手动操作成本极高；且大体量数据导出的CSV文件体积大、无断点续传能力、缺乏错误校验机制，很容易出现数据丢失、重复导入、类型错乱的问题，后续排查脏数据的成本远高于迁移本身。

1. MongoDB结构初始化优化 #

不要完全依赖Django迁移命令自动生成结构：

• 写完DRF对应的Model后，先核对模型逻辑：不要直接1:1照搬MySQL的三范式表结构，Mongo作为文档型数据库，适合将高频关联查询的字段做成嵌套文档，不要硬建外键关联，避免后续查询性能拉胯。
• 若使用Djongo作为Mongo引擎，执行迁移前先用python manage.py sqlmigrate <app名> <迁移版本号>查看生成的结构定义，核对字段类型、默认值、索引规则是否符合预期，核心业务的唯一索引、联合索引建议在Mongo Shell中手动创建，比自动迁移生成的可靠性更高。
• 若使用MongoEngine作为Mongo ODM，本身不走Django迁移体系，写完Document定义后手动执行索引创建即可，可控性更强。

2. 分场景选择数据迁移方案 #

完全不需要经过CSV中间文件做手动迁移，根据数据量级选对应方案即可：

• 百万级以内数据量：直接写Django自定义管理命令做直连迁移。在settings.py中给存量MySQL库配置单独的数据库连接别名（不要覆盖默认的Mongo连接），命令逻辑中按主键分页批量读取MySQL数据，逐行做字段类型转换、结构重组（比如将关联表数据拼接为嵌套结构），每1000~5000条做一次批量写入Mongo，写入时关闭有序写入选项提升性能，同时加上断点续传标记（比如记录上次迁移完成的MySQL主键ID）、错误日志、进度打印，迁移完成后直接做数据量对账、抽样字段校验，全程无中间文件，类型转换可控。
• 千万级以上大体量数据：不要走Django ORM读取MySQL，直接用Mongo官方的mongoimport工具，配合MySQL原生导出的JSON/BSON格式数据（不要用CSV）做批量导入，导入前临时调低Mongo的写入确认级别、关闭索引实时刷新，导入完成后再统一创建索引，迁移速度比CSV导入高3~10倍，且字段类型保留更完整；如果数据量过亿，可以用Spark做分布式分片同步，进一步压缩迁移窗口。
• 如果需要平滑切换流量，存量数据迁完后加一个短期的增量同步任务：基于MySQL核心表的update_time字段定时拉取增量变更的数据同步到Mongo，持续校验两边数据一致性，直到数据差为0再切流量到新的DRF服务，避免上线前的数据空窗问题。

3. 迁移后必做校验 #

• 核心表总条数对账，确保无数据丢失
• 随机抽取1%~5%的数据做字段值、类型校验，重点检查时间、金额、JSON类字段
• 核对Mongo侧索引是否全部创建完成，避免上线后出现慢查询

内容的提问来源于stack exchange，提问作者Abraham Escarrá