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

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

我的问题有几个部分组成：

（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

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

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

数据来自日文文本数据库，并且该列具有utf8_general_ci归类。

MySQL版本5.6.23在Windows XP上。

以下是其他相关变量（我认为）：

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 `

所以，表字符集UTF-16（原因我忘了），一个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需要简单地跳过一些有问题的行，那不是什么大问题。

来源

2015-04-20 user4652310

“似乎在转储文件中所有编码都是相同的方式” - 你的意思是一些看起来正确编码在sjis中，一些在utf8中？ –

回到这个错误，你能在“'randomimproperlydisplayingjapanesetext'，''），（508715,134707'”）之前找到这些字符吗？这就是问题所在。或者，也许这个文本中的转义被玷污了（sjis ）可能具有“'”作为有效字符的一个字节，这可能表示在倾倒sjis时mysqldump中的错误 –

@RickJames，（1）关于你的编码问题，我的意思是基本上mysqldump文件中的所有字符都是可读的，因此在* mysqldump文件内以相同的方式进行编码（对不起，也许这很明显）。（2）错误之前的文本是'INSERT INTO'troubletable'VALUES（x，x，x，x，x），（508715,134707''，但我认为问题是*之前显示的字符*错误语句，即在INSERT语句中的某个地方存在15000行这些记录没有被插入到数据库中现在我一次删除1000条记录来查找故障字符 – user4652310

sjis和utf8_general_ci是无关的。虽然可以在表中使用sjis和utf8，但它似乎是一种不必要的混合。

sjis和utf8是“字符集”。
sjis_japanese_ci和utf8_general_ci对应的“COLLATION”。
手头的问题涉及字符集。

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

在UTF8日本的HEX：

E381yy - 平假名
E383yy - 片假名
Ewxxyy - 汉字

为SJIS的HEX实际上任何组合很难“认识”。

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

回到问题...

当使用mysqldump，你是否也有--set-charset（而不是--skip-set-charset）？如果是这样，转储文件中应该有一个SET NAMES。检查它。它应该靠近顶部。如果它在那里，我们需要进一步挖掘，找出发生了什么问题。

如果它不在那里，你可以弥补它的缺席。在mysql声明中使用--default-character-set=xx，其中xx是sjis或utf8，具体取决于转储中的编码。

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

来源

2015-04-20 22:25:19

干杯的线索，我在更好的位置排除故障，但仍然没有运气。我编辑了我的问题以包含关于'SET NAMES'的进一步细节，以及表和列字符集的详细信息。 – user4652310

这个答案基本上是正确的，但只是为了强调：mysqldump的字符集需要与mysql输入的字符集相匹配。如果在[mysql]选项下的mysql配置文件中设置了default-character-set，我建议在[mysqldump]部分下设置相同的选项以避免这样的问题。仍然不确定为什么五十万记录加载没有问题，但.. – user4652310

在我的情况下，它是由导出和导入mysql版本之间的版本差异引起的。我的导出mysql是5.7.x（Ubuntu 16.04），但导入是5.5.x（Ubuntu 14.04）。通过following this guide将导入升级到5.7.x之后，它工作正常。

来源

2017-07-03 21:13:30 Deleet

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

回答

相关问题