Question

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

我的问题有几个部分：

（1）为什么mysql无法正确读取mysqldump输出的文件？（2）如何从文件中读取相关数据中的mysql？

下面是一些细节：

mysqldump -u username -p dbname > mydumpfile.sql很好（显然）

mysql -u testuser -p testdbname < mydumpfile.sql仅获取文件的一部分（约1/3），然后给出语法错误：

第249行的错误1064（42000）：您的SQL语法出错; 检查与您的MySQL服务器版本对应的手册正确的语法使用附近＆＃39; randomimproperlydisplayingjapanesetext＆＃39;，＆＃39;＆＃39;），（508715,134707＆＃39; at line 1

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

上一行的（大）插入语句语句未输入数据库。

数据来自具有日文文本的数据库，该列具有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\     |
+--------------------------+------------------------------+

修改根据下面的答案，我确定mysqldump中的一行SET NAMES，用于将其设置为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，而不是默认值，但这并没有改变问题。

表中加载的部分对插入的数据没有明显的问题，但是有太多的数据让我真正查看db数据或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后，它可以正常工作。

Answer 2

sjis和utf8_general_ci无关。虽然可以在客户端使用sjis，在表中使用utf8，但这似乎是不必要的混合。

sjis和utf8是＆＃34;字符集＆＃34;。
sjis_japanese_ci和utf8_general_ci对应＆＃34; COLLATION＆＃34;。
手头的问题涉及CHARACTER SETs。

检查您要插入的日文字符的字节（或来源） - 验证它们是2字节sjis编码还是3字节utf8编码。

utf8中的日语HEX：

E381yy - Hiragana
E383yy - Katakana
Ewxxyy - Kanji

HEX for sjis实际上是任何组合，因此难以识别＆＃34;。

同样用SELECT col, HEX(col) ...检查表格中的数据。也为其中一个表做（并为我们提供）SHOW CREATE TABLE。

回到问题......

使用mysqldump时，您有--set-charset（而不是--skip-set-charset）吗？如果是这样，转储文件中应该有SET NAMES。检查一下。它应该在顶部附近。如果它存在，我们需要进一步挖掘以找出问题所在。

如果不存在，您可以补偿它的缺席。在mysql语句中使用--default-character-set=xx，其中xx是sjis或utf8，具体取决于转储中的编码。

如果这些线索不够，请编辑您的问题，并回答我提出的问题。

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

2 个答案: