加载 mysqldump 文件时出现 sql 语法错误

Question

我在尝试加载 mysqldump 文件时收到语法错误。

我的问题有几个部分:

(1)为什么mysql无法正确读取mysqldump输出的文件？
(2) 如何让mysql从一个文件中读入相关数据？

这里是一些细节:

mysqldump -u username -p dbname > mydumpfile.sql一切顺利(显然)

mysql -u testuser -p testdbname < mydumpfile.sql仅通过文件的一部分(大约 1/3)，然后给出语法错误:

ERROR 1064 (42000) at line 249: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'randomimproperlydisplayingjapanesetext',''),(508715,134707' at line 1

显示为语法错误的文本是在新插入语句开始后不久。

上一行的(大)insert statement 语句没有被输入到数据库中。

数据来自日文数据库，列有 utf8_general_ci 排序规则。

Windows xp 上的 MySQL 版本 5.6.23。

以下是其他相关变量(我认为):

mysql> show variables like '%char%';
+--------------------------+------------------------------+
| Variable_name            | Value                        |
+--------------------------+------------------------------+
| character_set_client     | sjis                         |
| character_set_connection | sjis                         |
| character_set_database   | sjis                         |
| character_set_filesystem | binary                       |
| character_set_results    | sjis                         |
| character_set_server     | sjis                         |
| character_set_system     | utf8                         |
| character_sets_dir       | C:\mysql\share\charsets\     |
+--------------------------+------------------------------+

编辑 根据下面的答案，我确定是一个SET NAMES mysqldump 中的行以将其设置为 utf8。

这是 SHOW CREATE TABLE trouble_table结果:

CREATE TABLE `trouble_table` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `version_id` int(11) DEFAULT NULL,
  `myutf8column` varchar(100) CHARACTER SET utf8 DEFAULT NULL,
  `mysjisenumcolumn` enum('一式','＊',[a few other japanese charactes]) CHARACTER SET sjis DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `version_id` (`version_id`)
) ENGINE=InnoDB AUTO_INCREMENT=946033 DEFAULT CHARSET=utf16 `

于是，表字符集utf16(我忘了为什么)，一列utf8，一列sjis。在 msyqldump 文件中，我可以读取所有值，因此在转储文件中似乎所有值都以相同的方式编码。

SELECT HEX(mytuf8column)似乎确认 myutf8column 具有 utf8 编码(以下面提到的代码开头，即 E383xx，Ewxxyy)，而 mysjiscolumn 具有以 95 开头的十六进制值，所以我猜它可能是 sjis。

另外，看完this SOV question , 我检查并设置了 max_allowed_packet成为33554432 , 而不是默认值，但这并没有改变问题。

确实加载的表部分插入的数据没有明显的问题，但数据太多，我无法真正查看数据库数据或 mysqldump 文件并注意到可能导致的任何“奇怪”字符到mysql就憋死了。 (mysqldump 文件超过 50MB，所以以 db 标准来说它并不大，但大到读起来很麻烦，Notepad++ 和 emacs 似乎对此无能为力)

还有一件事，我对更改列排序规则感到紧张，因为我不想丢失任何数据(如果当前编码错误，将其更改为另一种编码是否安全？)。解析原始数据需要很长时间，因此我正在尝试制作备份副本。 编辑 根据下面的回答，我不再对更改排序规则感到紧张，因为它只是比较规则，而是对更改字符集感到紧张。

顺便说一下，如果 mysql 需要简单地跳过一些有问题的行，这没什么大不了的。

Answer 1

在我的例子中，这是由导出和导入 mysql 版本之间的版本差异引起的。我导出的 mysql 是 5.7.x (Ubuntu 16.04)，但导入的是 5.5.x (Ubuntu 14.04)。通过 following this guide 将导入升级到 5.7.x 之后, 它奏效了。