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

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

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

强烈建议Saw BigDump导入大型数据库。还可以找到一个链接，上面写着建议使用include column names in every INSERT statementDone的语法。(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/(以将CCD_ 3降低到500并且添加300的CCD_。再次运行，更多小时，相同错误。

然后，我将数据库重新导出到两个.sql转储中(其中一个转储包含所有超过100K记录的大型表(，重复，同样的错误。所以我停止使用Bigdump。

接下来是命令行！使用控制台2，我运行了source mydump.sql30小时过去。然后出现错误：

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-300000行之间。我也不认为30个小时(在一台速度极快的机器上(对于一个只有1Gb的进口来说是正常的，但我可能错了。

我还应该尝试其他哪些选项？这是导出的格式吗？它应该压缩还是不压缩？有没有更快的进口方式？有什么办法让这件事进展得更快吗？

谢谢！

编辑

感谢一些搜索和@Bill Karwin的建议，我现在的位置是：

使用ssh获取了一个新的mysqldump并下载了它
导入数据库10次。每次都快得多(5-10分钟(，所以固定了荒谬的导入时间。
- 使用的命令行，>source dump.sql
但是，从同一个dump.sql文件导入的每个文件都有不同数量的记录。在300万张记录中，它们的差异在600到200000张之间。其中一个进口产品的记录比原来的多了12000条。我尝试过使用和不使用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

让phpMyAdmin显示InnoDB表的确切记录数？

将大型MySQL表导出为多个较小的文件

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

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

将变量设置为NULL的错误似乎是BigDump的限制。BigDump常见问题解答中提到了这一点。我从未在使用命令行客户端恢复转储文件时看到过这些错误。

以下是一些建议：

请确保您的本地MySQL数据目录位于本地连接的驱动器上，而不是网络驱动器。
使用mysql命令行客户端，而不是phpMyAdmin或BigDump。
```
mysql> source mydump.sql
```
转储文件大多是一长串INSERT语句，您可以阅读《INSERT语句的速度》，了解有关加快INSERT的提示。请务必阅读它链接到的子页面。
例如，当您导出数据库时，请检查单选按钮是否"在每个insert语句中插入多行"(这与BigDump不兼容，但当您在mysql客户端中使用source时，性能会更好(。
建议生产使用耐久性设置，但它们会带来一些性能损失。听起来你只是想让一个开发实例运行，所以降低耐久性可能是值得的，至少在你导入的时候是这样。MySQL社区经理Morgan Tocker的博客中有一个关于降低耐久性的好总结：降低MySQL测试的耐久性。

关于你的新问题和错误：

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

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

您的某些数据行未能加载
在导入过程中保留@time_zone和其他设置的会话变量将丢失，因为它们的作用域是会话。当重新连接发生时，您将获得一个新会话

解决方法是增加你的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计数只是一个估计——它可能非常遥远，比如表实际行数的+/-10%(或更多(。即使您没有更改表中的任何数据，报告的数字也可能不时发生变化。对表中的行进行计数的唯一真正方法是使用SELECT COUNT(*) FROM SomeTable。

解决方案

对于任何想要循序渐进的人：

使用PuTTY，获取数据库的mysql转储(不要包括>右侧的所有内容，并用适当的信息替换所有大写字母(

> mysqldump -uUSERNAME -p DATABASENAME > DATABASE_DUMP_FILE_NAME.sql

你会得到一个密码提示，输入，然后点击回车键。等到你再次得到提示。如果您使用的是FTP客户端，请转到主机的根目录，您应该在那里看到您的文件，然后下载它
通过导航到mysql.exe文件所在的位置(有几种方法可以做到这一点，这是其中之一(并键入以下内容，在本地获得mysql提示：

> mysql.exe -use NEW_DATABASE -u USERNAME

现在您进入mysql提示符。打开警告。。。以防万一

mysql > W;

将max_allowed_packet增加到真正的Gig。我看到有人提到也要更改net_buffer_length，但在5.1.31之后，它似乎没有更改(底部的链接(

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

现在导入您的sql文件

mysql > source C:pathtoDATABASE_DUMP_FILE_NAME.sql

如果您想检查是否所有导入的记录，您可以键入SELECT COUNT(*) FROM SomeTable或

转到C:\wamp\apps\phpmyadmin\config.inc.php
在?>之前的底部添加：

/* Show the exact count of each row */

$cfg['MaxExactCount'] = 2000000;

这只建议用于开发平台，但在必须扫描一堆表/数据库时非常方便。可能会放慢大型布景的制作速度

相关内容

最新更新

热门标签：