我已经做了好几天了，非常沮丧。
拥有一个Magento数据库，大约1Gb，包含3MM记录 - 需要进行备份并将其导入我的本地计算机。本地机器正在使用16 Gb RAM的全新游戏机规格上运行WAMP。使用PHPMyAdmin将db导出到.sql文件中。
强烈建议使用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建议，我在这里：
>source dump.sql 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?
答案 0 :(得分：4)
不，这不是正常的恢复时间，除非您在15年前的计算机上运行MySQL，或者您尝试通过非常慢的网络将数据库写入共享卷。我可以在大约45分钟内导入大约那个大小的数据转储，即使在x-small EC2实例上也是如此。
将变量设置为NULL的错误似乎是BigDump的限制。它在BigDump FAQ中提到过。我从未在使用命令行客户端恢复转储文件时看到这些错误。
所以这里有一些建议：
确保您的本地MySQL数据目录位于本地连接的驱动器上 - 而不是网络驱动器。
使用mysql命令行客户端，而不是phpMyAdmin或BigDump。
mysql> source mydump.sql
转储文件主要是很长的INSERT语句列表，您可以阅读Speed of INSERT Statements以获取有关加速INSERT的提示。请务必阅读它链接到的子页面。
例如，在导出数据库时，检查单选按钮是否为＆＃34;在每个INSERT语句中插入多行＆＃34; （这与BigDump不兼容，但在mysql客户端中使用source时性能更好。）
建议将耐久性设置用于生产用途，但它们会带来一些性能损失。听起来你只是想让一个开发实例运行，所以降低耐用性可能是值得的，至少在你进行导入时。 MySQL社区经理Morgan Tocker的博客中提到了降低耐久性的一个很好的总结：Reducing MySQL durability for testing。
重新提出新问题和错误：
很多人在导入由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。
答案 1 :(得分：1)
<强>解
对于任何想要一步一步的人：
> mysqldump -uUSERNAME -p DATABASENAME > DATABASE_DUMP_FILE_NAME.sql
> mysql.exe -use NEW_DATABASE -u USERNAME
mysql > \W;
mysql > SET global max_allowed_packet = 1024*1024*1024;
mysql > source C:\path\to\DATABASE_DUMP_FILE_NAME.sql
如果要检查导入的所有记录是否可以键入SELECT COUNT(*) FROM SomeTable或
?>添加： /* Show the exact count of each row */
$cfg['MaxExactCount'] = 2000000;