mysql - 大型 (1G) MySQL 数据库需要 30 小时才能导入 WAMP，加上 Null 错误

Question

我已经为此工作了几天，非常沮丧。

有一个 Magento 数据库，大约 1Gb 和 3MM 记录 - 需要进行备份并将其导入到我的本地机器上。本地机器在具有 16 Gb RAM 的全新游戏装备规范上运行 WAMP)。使用 PHPMyAdmin 将数据库导出到 .sql 文件中。

强烈建议使用 Saw BigDump 导入大型数据库。还可以找到一个链接，上面写着推荐使用 include column names in every INSERT statement 的语法。完毕。 ( http://www.atomicsmash.co.uk/blog/import-large-sql-databases/ )

开始导入。几个小时过去了(大约 3-4 小时)。得到一个错误:Page unavailable, or wrong url!更多搜索，尝试建议(主要在这里: http://www.sitehostingtalk.com/f16/bigdump-error-page-unavailable-wrong-url-56939/ )删除 $linespersession到 500 并添加 $delaypersession 300。再次运行，更多小时，同样的错误。

然后我将数据库重新导出到两个 .sql 转储(一个保存所有超过 100K 记录的大表)，重复，同样的错误。所以我不再使用 Bigdump。

接下来是命令行!使用 Console2 我跑了 source mydump.sql . 30 小时 过去。然后报错:
ERROR 1231 (42000): Variable 'character_set_client' can't be set to the value of 'NULL' ERROR 1231 (42000): Variable 'collation_connection' can't be set to the value of 'NULL'
更多的搜索，真正多样的解释。我尝试使用之前的拆分文件 - 再次运行它，同样的错误。

我无法弄清楚是什么导致了这两个错误。我知道我在两个不同的导出中遇到了相同的错误。我知道有一些表在 1-300,000 行之间。我也不认为 30 小时是正常的(在尖叫的快速机器上)仅导入 1Gb，但我可能是错的。

我应该尝试哪些其他选择？是导出格式吗？应该压缩还是不压缩？有没有更快的导入方式？有什么办法可以让这个过程更快吗？

谢谢!

编辑

感谢一些搜索和@Bill Karwin 的建议，这就是我所在的位置:

使用 ssh 获取一个新的 mysqldump 并下载它。

导入了 10 次不同的数据库。每次都快得多(5-10 分钟)，因此修复了荒谬的导入时间。

使用命令行，>source dump.sql

但是，来自同一个 dump.sql 文件的每次导入都有不同数量的记录。在 300 万条记录中，它们相差 600 到 200,000 条记录。其中一个导入的记录比原始记录多 12,000 条。我试过设置和不设置 foreign_key_checks = 0;我尝试使用完全相同的设置多次运行相同的查询。每次的行数都不一样。

我现在也收到这些错误:
ERROR 1231 (42000): Variable 'time_zone' can't be set to the value of 'NULL' ERROR 1231 (42000): Variable 'sql_mode' can't be set to the value of 'NULL' ERROR 1231 (42000): Variable 'foreign_key_checks' can't be set to the value of 'NULL' ERROR 1231 (42000): Variable 'unique_checks' can't be set to the value of 'NULL' ERROR 1231 (42000): Variable 'character_set_client' can't be set to the value of 'NULL' ERROR 1231 (42000): Variable 'collation_connection' can't be set to the value of 'NULL' ERROR 1231 (42000): Variable 'sql_notes' can't be set to the value of 'NULL'
从我读到的内容来看，这些似乎并不那么重要。还有其他警告，但我似乎无法确定它们是什么。

有任何想法吗？

编辑:解决方案已在此处删除并在下面作为单独的帖子列出

引用文献:

https://serverfault.com/questions/244725/how-to-is-mysqls-net-buffer-length-config-viewed-and-reset

http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_net_buffer_length

Make phpMyAdmin show exact number of records for InnoDB tables?

Export a large MySQL table as multiple smaller files

https://dba.stackexchange.com/questions/31197/why-max-allowed-packet-is-larger-in-mysqldump-than-mysqld-in-my-cnf

Answer 1

不，这不是正常的恢复时间，除非您在一台 15 岁的计算机上运行 MySQL，或者您试图通过非常慢的网络将数据库写入共享卷。我可以在大约 45 分钟内导入大约该大小的数据转储，即使在 x-small EC2 实例上也是如此。

将变量设置为 NULL 的错误似乎是 BigDump 的限制。它在 BigDump FAQ 中提到.我从未见过使用命令行客户端恢复转储文件时出现的这些错误。

所以这里有一些建议:

确保您的本地 MySQL 数据目录位于本地连接的驱动器上——而不是网络驱动器上。

使用 mysql命令行客户端，而不是 phpMyAdmin 或 BigDump。

mysql> source mydump.sql

转储文件大多是一长串INSERT语句，可以阅读Speed of INSERT Statements有关加速 INSERT 的提示。请务必阅读它链接到的子页面。

例如，当您导出数据库时，检查“在每个 INSERT 语句中插入多行”的单选按钮(这与 BigDump 不兼容，但在 mysql 客户端中使用 source 时性能更好)。

建议将耐久性设置用于生产用途，但它们会带来一些性能损失。听起来您只是想让开发实例运行，因此降低持久性可能是值得的，至少在您进行导入时是这样。 MySQL 社区经理 Morgan Tocker 的博客中对降低持久性做了很好的总结:Reducing MySQL durability for testing .

重新回答您的新问题和错误:

很多人在导入由 phpMyAdmin 或 Drupal 或其他工具创建的大型转储文件时都会报告类似的错误。

最可能的原因是转储文件中的某些数据大于 max_allowed_packet .此 MySQL 配置设置是单个 SQL 语句或单个数据行的最大大小。当您在单个 SQL 语句中超过此值时，服务器将中止该 SQL 语句并关闭您的连接。 mysql 客户端尝试自动重新连接并恢复转储文件的来源，但有两个副作用:

您的某些数据行无法加载。

保留 @time_zone 的 session 变量导入期间的其他设置将丢失，因为它们的范围仅限于 session 。当重新连接发生时，您将获得一个新 session 。

解决方法是增加您的 max_allowed_packet . MySQL 5.6 上的默认级别为 4MB，早期版本仅为 1MB。您可以找出此配置的当前值:

mysql> SELECT @@max_allowed_packet;
+----------------------+
| @@max_allowed_packet |
+----------------------+
|              4194304 |
+----------------------+

您可以将其增加到 1GB:

mysql> set global max_allowed_packet = 1024*1024*1024;

然后再次尝试导入:

mysql> source mydump.sql

此外，如果您使用类似 SHOW TABLE STATUS 的命令测量表的大小。或查询 INFORMATION_SCHEMA.TABLES ，你应该知道TABLE_ROWS count 只是一个估计值——它可能相差很远，比如表实际行数的 +/- 10%(或更多)。即使您没有更改表中的任何数据，报告的数字甚至可能会不时更改。计算表中行数的唯一正确方法是使用 SELECT COUNT(*) FROM SomeTable .