有时我需要将MySQL数据库（db1）复制到另一个数据库（db2）。我发现这个命令简洁有效：
mysqldump --opt db1 | mysql db2
它工作正常，但现在它因以下错误而中断：
第1586行的错误1064（42000）：您的SQL语法出错; 检查与您的MySQL服务器版本对应的手册 在'mysqldump附近使用正确的语法：无法执行'SHOW TRIGGERS LIKE'seat_table_name''：第1行的MySQL服务器
首先想到的是数据库太大（未压缩的SQL转储大约是1G，目前是1090526011字节，准确地说），就像这样管道它。当我mysqldump > file然后mysql < file时它工作正常，没有错误。错误消息（some_table_name）中提到的表不大或特殊。
第二个想法来自错误消息可能被截断的印象，并且它表示
“...... MySQL服务器已经消失”
对此的快速研究表明，可能会达到最大数量的打开文件（对于MySQL和/或系统）。所以我尝试将--skip-lock-table添加到mysqldump并提升open-files-limit，但没有运气，同样的错误。
明显的解决方案是进行转储然后导入（因为它工作正常），但管道似乎更好，更干净（让我知道我是不是错了），而且我很想知道是什么原因造成的问题。我是否达到了影响命令管道的限制？
我一直在托管服务器上执行此操作，在Linux和我的开发机器上运行MySQL 5.1.60 - 在Linux上运行MySQL 5.1.58。后者给出了一个不同的错误：
mysqldump：错误2013：在查询期间丢失了与MySQL服务器的连接 在表格
时other_table_name转储到行：7197
更新：问题通过单独的转储和导入解决，没有管道。即使我觉得这不是我的问题的真正答案，但ssmusoke的建议最重要的是得到了接受的答案。
答案 0 :(得分：5)
“MySQL服务器已经消失”是最大数据包错误的症状。 http://dev.mysql.com/doc/refman/5.0/en/gone-away.html
修改您的命令，为max_allowed_packet指定一个更大的值。
mysqldump --opt db1 | mysql --max_allowed_packet=32M db2
默认值为1M。 获得正确的价值可能需要反复试验。 http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet
答案 1 :(得分：4)
问题可能是服务器上的负载过高而同时进行转储和加载。这也意味着你失去了一些优化，比如扩展插入，能够禁用外键，这可以在你转储文件然后导入它时实现。
我建议您使用mysqldump生成备份，然后使用mysql加载它。这样，服务器上的负载就会减少，就像你说它总能工作一样。您甚至可以将其自动化为bash脚本来执行这两项操作，这样您就不需要执行mysqldump和加载命令。
答案 2 :(得分：2)
您是否需要重定向stderr流以及mysqldump中的stdout？错误消息可能与转储输出交错。尝试
mysqldump --opt db1 | mysql db2
答案 3 :(得分：2)
问题是您正在将stderr重定向到stdout，因此任何错误都被解释为SQL。删除2＆gt;＆amp; 1。然后会出现真正的错误。
答案 4 :(得分：0)
备份可能达到MySQL超时限制。
可以在my.cnf中更改变量
net_read_timeout = 120
net_write_timeout = 900
如果您希望更改这些设置而无需重新启动MySQL，则可以使用以下SQL语句执行此操作：
set global net_read_timeout = 120;
set global net_write_timeout = 900;
^你可能需要超级特权