通过管道 mysqldump 到 mysql

有时我需要将MySQL数据库（db1）复制到另一个数据库（db2）。我发现这个命令简洁有效：

mysqldump --opt db1 | mysql db2

它工作正常，但现在它因以下错误而中断：

ERROR 1064 (42000)，位于第 1586 行：您的 SQL 语法有错误； 检查与您的 MySQL 服务器版本对应的手册 在 'mysqldump: 无法执行 'SHOW TRIGGERS 附近使用的正确语法 LIKE 'some_table_name'': MySQL 服务器 ' 在第 1 行

首先想到的是数据库太大（准确地说，未压缩的 SQL 转储>1G，目前为 1090526011 字节），无法像这样进行管道传输。当我做mysqldump > file进而mysql < file它工作正常，没有错误。错误消息中提到的表（some_table_name）并不大或特殊。

第二个想法来自错误消息可能被截断的印象，并且它说

“...MySQL 服务器已经消失”

对此进行的快速研究表明，可能已达到打开文件的最大数量（对于 MySQL 和/或系统）。所以我尝试添加--skip-lock-table to mysqldump并提高open-files-limit，但运气不好，同样的错误。

明显的解决方案是先转储然后导入（因为它工作正常），但管道对我来说似乎更好、更干净（如果我错了，请告诉我），而且我很好奇找出导致此问题的原因。我是否达到了影响命令管道的某些限制？

我一直在托管服务器上执行此操作，在 Linux 上运行 MySQL 5.1.60，在我的开发机器上运行 MySQL 5.1.58。后者给出了一些不同的错误：

mysqldump：错误 2013：查询期间丢失与 MySQL 服务器的连接 倾倒桌子时other_table_name位于行：7197

更新：通过单独转储和导入（无需管道）可以解决问题。尽管我觉得这并不能真正回答我的问题，但 ssmusoke 的建议是最中肯的，导致答案被接受。

“MySQL 服务器已消失”是最大数据包错误的症状。http://dev.mysql.com/doc/refman/5.0/en/gone-away.html http://dev.mysql.com/doc/refman/5.0/en/gone-away.html

修改命令以指定更大的 max_allowed_pa​​cket 值。

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_pa​​cket http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet