有时我需要将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_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 http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
