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

（對於那些從搜索引擎來到這個問題的人），檢查你的存儲過程是否聲明了一個自定義分隔符，因為這是當引擎無法弄清楚如何終止語句時可能會看到的錯誤：

錯誤1064（42000）在第3行：您的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 2

您是否選擇了特定的數據庫：

USE database_name

除此之外，我無法想到出現此錯誤的任何原因。

Answer 3

對我來說，我有一個

create table mytable ( 
    dadada 
)

並在最后忘了分號。

所以看起來這個錯誤可能在簡單的語法錯誤后發生。 就像它說..我想你永遠不能仔細閱讀有用的編譯器評論。

Answer 4

我有這個，它是創建語法，改為--create-options，生活更好

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

而那恢復得很好。

Answer 5

終於得到了解決方案。

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

錯誤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 7

我有這個錯誤，因為使用mysql / mariadb保留字：

INSERT INTO tablename (precision) VALUE (2)

應該

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

Answer 8

檢查轉儲文件。 在開始時看起來像一個流浪的角色。 SQL不是世界的標准，MySQL導入器需要MySQL友好的SQL。 我願意打賭你的出口商做了一些時髦的事情。

您可能需要按一下文件才能使它與MySQL一起使用。

Answer 9

我碰到了一次 - 對我來說，刪除轉儲文件開頭的所有注釋掉的行是解決了問題的原因。 看起來這是一個空白錯誤。

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文件中打印stdout警告（如果mysqldump正在打印它的話）。

Answer 15

ERROR 1064 (42000) at line 1:

這個錯誤很常見。 發生此錯誤的主要原因是：當用戶意外編輯或錯誤編輯.sql文件時。