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

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

USE database_name

除此之外我无法想到出现此错误的任何原因。

Answer 2

（对于那些来自搜索引擎的问题），请检查您的存储过程是否声明了自定义分隔符，因为这是您在引擎无法确定如何终止语句时可能会看到的错误：

第3行的错误1064（42000）：您的SQL语法出错; 检查与您的MySQL服务器版本对应的手册正确的语法使用近＆＃39;＆＃39;在线...

如果您有数据库转储，请参阅：

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 3

对我来说，我有一个

create table mytable ( 
    dadada 
)

最后忘记了分号。

因此看起来在简单语法错误之后可能会发生此错误。就像它说的那样..我想你永远不能仔细阅读有用的编译器评论。

Answer 4

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

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

这很好地恢复了。

Answer 5

检查您的转储文件。在开始时看起来像一个流浪的角色。 SQL不是世界的标准，MySQL导入器需要MySQL友好的SQL。我愿意打赌你的出口商做了一些时髦的事。

您可能需要按一下该文件才能使其与MySQL一起使用。

Answer 6

我遇到过这一次 - 对我来说，删除转储文件开头的所有注释掉的行就是修复问题的原因。看起来这是一个空白错误。

Answer 7

终于找到了解决方案。

首先.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 8

错误1064经常发生在丢失DELIMITER语句时如：create function，create trigger .. 确保在每个语句之前添加DELIMITER $$并以$$ DELIMITER结束它像这样：

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

END $$
DELIMITER ;

Answer 9

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

INSERT INTO tablename (precision) VALUE (2)

应该是

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

Answer 10

这是我的情况：我忘记在'

之前添加);

file.sql结束，错误：

...
('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);

file.sql结束，没有错误：

...
('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 11

如果错误前面的行包含COMMENT ''，请填写脚本中的注释或删除空注释定义。我在MySQL Workbench生成的脚本中找到了这个。

Answer 12

我收到了这个错误

错误1064（42000）

因为下载的.sql.tar文件以某种方式损坏了。再次下载和解压缩解决了这个问题。

Answer 13

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

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

请注意，列名包含在`（标签上方的字符）中，而不包含在引号中。

Answer 14

面对同样的问题。确实，文件开头的SQL错误，因为在转储时我这样做了：

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

哪个文件的开头写的东西在stdout中是：

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

导致还原时出现该错误。

因此，删除SQL转储的第一行可以进行正确的还原。

看看原始问题中还原的方式，很有可能像我的一样完成转储，从而导致在SQL文件中输出标准输出警告（如果那时mysqldump将其打印回去）。 / p>

Answer 15

ERROR 1064 (42000) at line 1:

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

MySQL中的错误1064（42000）

15 个答案: