我不确定这个问题是否应该发布在SuperUser上，因为我们正在使用Workbench中的内置迁移向导，请告诉我是否应该移动此问题。
目标
我们目前正在将一个数据库从一个服务器迁移到另一个服务器，由于MySQL Workbench具有名为Migration Wizard的内置功能，因此我们认为可以轻松地进行迁移。我们有16个不同的数据库模式需要迁移，大小各异（最小为3 MB，最大为76 GB）。
问题
我们开始尝试迁移其中一个中到大型数据库，它占用14.7 GB的空间，一开始进行得很好，但在成功迁移了其中一半的表之后，我们收到了“MySQL Server has gone away”的错误消息。确保连接稳定并使用电缆连接它（也许是无线信号丢失了？），并确保拥有完整的权限，并使用root用户进行迁移，但我们仍然收到“Server has gone away”错误消息。
我们接着尝试较小的数据库，它们运行良好，所以我们认为可能是超时问题。我们尝试删除超时设置，但对于较大的数据库仍然出现相同的错误。真正困扰我们的是我们目前正在经历的事情。
当我们尝试对150 MB的数据库执行此操作时，迁移向导正确地完成了迁移，没有任何错误或警告。只是出于好奇我运行了以下代码：
SELECT table_name AS "Table",
round(((data_length + index_length) / 1024 / 1024), 2) "Size in MB"
FROM information_schema.TABLES
WHERE table_schema = "TableName"
ORDER BY "Table";
为确保表的大小正确，令人惊讶的是，我们源数据库中的所有表的总和为150 MB，但目标数据库中的总和只有94 MB。
问题：除了超时和权限之外，我们得到“服务器已关闭”错误的其他原因可能是什么？迁移向导为什么会说迁移成功而没有警告或错误，但实际上只迁移了约60%的数据？迁移向导可信吗，还是不能信任表大小查询？我们做错了吗，您推荐另一种更稳定的迁移数据库的方法吗？
MySQL版本：5.1.41（Ubuntu）。
我们还检查了每个模式中每个表中行的数量，虽然大多数都是正确的，但有些是错误的。这就是数据不一致性的问题所在。在150 MB / 94 MB的示例中，有25个表。其中23个表是正确的，有2个表是错误的。在源中，其中一个表具有257万行，但只有其中的150万行最终进入目标表。
再次运行相同的查询已经给出了94、150、8和24个表，现在第四次它成功地迁移了整个数据库。我猜问题可能出在别的地方，但我却想不明白是什么原因。迁移150 MB的数据用了92分钟。按比例计算，迁移75 GB的数据库需要大约一个月的时间 - 明显有问题。
