MySQL 中的错误 1064 (42000)

Question

我正在尝试使用从 MS SQL Azure 数据库创建的数据库转储来填充新的 MySQL 空数据库，但出现以下错误

第 1 行出现错误 1064 (42000)：您的 SQL 语法有错误； 检查与您的 MySQL 服务器版本对应的手册 在第 1 行“I”附近使用的正确语法

我使用 mysqldump 来执行此操作，并在命令提示符中使用了类似于以下内容的命令：

mysql --user=rootusername --pasword=password databasename < dumpfilename.sql

Mysqldump 花了大约 30 分钟来显示此错误消息。

Answer 1

当语句周围缺少 DELIMITER 时，通常会出现错误 1064，例如：创建函数、创建触发器。
确保在每个语句之前添加 DELIMITER $$ 并以 $$ DELIMITER 结束
像这样：

DELIMITER $
CREATE TRIGGER `agents_before_ins_tr` BEFORE INSERT ON `agents`
  FOR EACH ROW
BEGIN

END $
DELIMITER ; 

Answer 2

检查你的转储文件。一开始看起来就像是一个流浪角色。 SQL 并不是世界各地的标准，MySQL 导入程序期望 MySQL 友好的 SQL。我敢打赌你们的出口商做了一些奇怪的事情。

您可能需要稍微修改该文件才能使其与 MySQL 一起工作。

Answer 3

我曾经遇到过这个问题 - 对我来说，删除转储文件开头的所有注释掉的行就可以解决问题。看起来这是一个空格错误。

Answer 4

终于得到了解决方案。

第一个 .sql 文件转换为 UTF8。

然后使用这个命令

mysql -p -u root --default_character_set utf8 test </var/201535.sql

---root 是用户名

---test 是数据库名

或者

mysql -p -u root test < /var/201535.sql 

---root 是用户名

---test 是数据库名

Answer 5

这是我的情况：
End of file.sql without error:添加 ' 之前 );

我忘记在 ); End of file.sql with error:

...
('node','ad','0','3879','3879','und','0','-14.30602','-170.696181','0','0','0'),
('node','ad','0','3880','3880','und','0','-14.30602','-170.696181','0','0','0);

End of file.sql with error: End of file.sql without error:

...
('node','ad','0','3879','3879','und','0','-14.30602','-170.696181','0','0','0'),
('node','ad','0','3880','3880','und','0','-14.30602','-170.696181','0','0','0');

Answer 6

如果错误之前的行包含 COMMENT ''，请填充脚本中的注释或删除空注释定义。我在 MySQL Workbench 生成的脚本中发现了这一点。

Answer 7

我收到这个错误

错误 1064 (42000)

，因为下载的 .sql.tar 文件因某种原因损坏。再次下载并解压就解决了这个问题。

Answer 8

在查询中进行以下更改解决了此问题：

INSERT INTO table_name (`column1`, `column2`) values ('val1', 'val2');

请注意，列名称包含在`（选项卡上方的字符）中，而不是引号中。

Answer 9

面临同样的问题。事实上，文件开头的 SQL 是错误的，因为在转储时我做了：

mysqldump -u username --password=password db_name > dump.sql

在文件开头写了 stdout 中的内容：

mysqldump：[警告]在命令行界面上使用密码可能不安全。

导致恢复引发该错误。

因此，删除 SQL 转储的第一行可以实现正确的恢复。

查看原始问题中恢复的完成方式，很可能转储的完成方式与我的类似，导致在 SQL 文件中打印标准输出警告（如果当时 mysqldump 正在打印它）。

Answer 10

当您使用mysqldump转储文件时，请使用--result-file选项而不是>运算符。

通过使用 >，输出文件将以 UTF-16 编码保存，即使您提供例如 --default-character-set=utf8mb4 > 选项。不知何故，mysql无法正确处理此编码

当您使用mysql恢复数据库时，您可以使用<加载文件

Answer 11

ERROR 1064 (42000) at line 1:

这个错误很常见。发生此错误的主要原因是：当用户意外编辑或错误编辑.sql文件时。

Answer 12

（对于那些通过搜索引擎提出此问题的人），请检查您的存储过程是否声明了自定义分隔符，因为当引擎无法弄清楚如何终止语句时，您可能会看到以下错误：

第 3 行出现错误 1064 (42000)：您的 SQL 语法有错误；
检查与您的 MySQL 服务器版本对应的手册
在行附近 '' 使用正确的语法...

如果您有数据库转储并看到：

DROP PROCEDURE IF EXISTS prc_test;
CREATE PROCEDURE prc_test( test varchar(50))
BEGIN
    SET @sqlstr = CONCAT_WS(' ', 'CREATE DATABASE',  test, 'CHARACTER SET utf8 COLLATE utf8_general_ci');
    SELECT @sqlstr;
    PREPARE stmt FROM @sqlstr;
    EXECUTE stmt;
END;

尝试使用自定义 DELIMITER 进行包装：

DROP PROCEDURE IF EXISTS prc_test;
DELIMITER $
CREATE PROCEDURE prc_test( test varchar(50))
BEGIN
    SET @sqlstr = CONCAT_WS(' ', 'CREATE DATABASE',  test, 'CHARACTER SET utf8 COLLATE utf8_general_ci');
    SELECT @sqlstr;
    PREPARE stmt FROM @sqlstr;
    EXECUTE stmt;
END;
$
DELIMITER ;

Answer 13

您是否像这样选择了特定的数据库：

USE database_name

除此之外，我想不出此错误的任何原因。

Answer 14

对我来说，我有一个

create table mytable ( 
    dadada 
)

并且忘记了最后的分号。

所以看起来这个错误可能是在简单的语法错误之后发生的。就像它说的那样......我猜你永远无法足够仔细地阅读有用的编译器注释。

Answer 15

由于使用 mysql/mariadb 保留字，我遇到了此错误：

INSERT INTO tablename ( precision) VALUE (2)

应该是

INSERT INTO tablename (` precision`) VALUE (2) >

Answer 16

我有这个，它是创建语法，更改为--create-options，生活变得更好

mysqldump -u [user] -p -create-options [DBNAME] >[DumpFile].sql

而且恢复得很好。