我意识到这个问题已经几年了 - 但最近有很多人询问是否可以使用我开发的
工具(
https://virtual.blue/apps/json-converter)来实现 OP 所要求的功能(将 MongoDB 转换为 SQL)，所以我猜这仍然是人们想要的。继续阅读，了解为什么我对此并不感到惊讶。
简短回答是：这个工具能否帮助你，或许吧。如果你的现有数据关系不太复杂，并且你的数据库不是特别大，那么它可能值得一试。
然而，我认为试图解释这种转换的问题可能会有所帮助，因为到目前为止，所有我看到的答案都是“尝试工具 X”或“先将其转换为格式 Y，然后使用实用程序 Z 将其导入 MySQL”。即没有考虑到在这样做之后得到的结果是否在数据关系和完整性方面是有意义的。
例如，您可以将整个数据库转储放入单个SQL表的单个字段中（实际上可能由于空间限制而无法实现，但希望您明白我的意思）。然后您的数据库将是“MySQL格式”，但对任何人都没有任何用处。
关键是，您实际上想要的是一个完全定义的数据库模型，正确地封装了所有固有数据关系（正如所知的“
数据库规范化”）。如果您的转换过程错误地处理了这些关系，则会产生损坏的模型，并且您尝试运行的任何查询都可能返回无意义的结果。不幸的是，没有什么神奇的工具会“知道”在MySQL中表示数据的最佳方法，闭上眼睛并将其推到一堆随机工具中，不太可能奇迹般地获得您想要的结果。
在“NoSQL”哲学（潮流）中存在一个根本性问题，他们向人们推销了“非关系型数据”的虚假概念。当我第一次听到这个时，我的第一个想法是，“那怎么行？毕竟所有的数据都是有关系的吧？”从事实来看，我们正在逐渐获得越来越多的证据证明我的直觉是正确的。（“NoSQL？为什么要停在那里？我选择‘NoDatabase’。它完全没有返回结果，但速度确实很快！”）
NoSQL的疯狂将几个重要的基本工程原则抛到了一边。我们大声呼喊着“不要硬编码！”，“DRY！”（不要重复自己），因为这些行动会给系统带来缺乏灵活性的影响。传统智慧在建议“创建一个完整描述所有数据关系的模型”时，正是出于同样的灵活性论点。然后你可以对其执行任意查询并期望得到有意义的结果。“是的，但有一堆查询我们永远不需要运行，”NoSQL支持者说。但我们肯定已经从“我们永远不需要做的事情”中吸取了教训吧？（“我大量使用硬编码，因为我知道我永远不想改变我的代码。”嗯...）
关于速度的争论在很大程度上是无意义的。假设您经常执行复杂的9个表连接操作，性能会相对较差。因此，创建一个索引并将其缓存起来，用一些磁盘空间换取速度。NoSQL的哲学是为了速度而交换数据完整性，这完全没有任何意义。
当您生成快速查找索引（缓存/表/映射等）时，实际上是在创建模型上的视图。如果您的模型发生更改，您可以轻松地更新视图。从模型到视图很容易-它是一对多的操作，您处于熵的正确侧面。
然而，当您选择MongoDB时，您实际上决定创建视图，而不必描述您的基本模型。现在您发现有一些查询想要运行，但无法运行-因此，您想要转移到SQL并正确地对数据进行建模。问题是，现在您想要从视图转移到模型。现在你处于熵的错误侧面。您的视图是模型基本关系的有损表示。您不能指望工具“翻译”您的数据库，因为您要求它插入最初未定义的新关系。这些是现实世界中不可机器猜测的关系。工具无法知道原本旨在建立哪些关系。
简而言之，唯一可靠的方法是亲自动手。一个理解你正在建模的系统的聪明人需要坐下来仔细地编写（可能是大量的）代码，有效地遍历数据并解决所有不足表示的数据关系。如果你的数据很复杂，那么这将会是一件头痛的事情，没有捷径可走。
如果你的数据仍然相对简单，我建议尽快进行转换，以免变得困难。在这种情况下，我的工具（
https://virtual.blue/apps/json-converter）可能能够提供帮助。
（在提出所有这些胡说八道之前，他们真的应该先问问物理学家……！）
