向MySQL发出命令时,出现错误#1064“语法错误”。
这是什么意思?
我该如何解决?
Answers:
TL; DR
错误#1064表示MySQL无法理解您的命令。要解决这个问题:
阅读错误消息。 它准确地告诉您MySQL在命令中哪里混淆了。
检查您的命令。如果您使用的编程语言来创建你的命令,使用
echo
,console.log()
或同等学历,以显示完整的命令,所以你可以看到它。检查手册。通过与当时MySQL的预期进行比较,该问题通常很明显。
检查保留字。如果错误发生在对象标识符上,请检查它是否不是保留字(如果是,请确保正确引用了该字)。
错误消息可能看起来像傻瓜,但它们(通常)提供了令人难以置信的信息,并且提供了足够的详细信息来查明出了什么问题。通过确切地了解MySQL会告诉您什么,您可以武装自己解决将来的任何此类问题。
与许多程序一样,MySQL错误是根据发生的问题的类型进行编码的。 错误#1064是语法错误。
虽然“语法”是许多程序员仅在计算机环境中遇到的词,但实际上它是从更广泛的语言学中借用的。它指的是句子结构:即语法规则;换而言之,就是定义在语言中构成有效句子的规则。
例如,以下英语句子包含语法错误(因为不定冠词“ a”必须始终在名词之前):
这句话包含语法错误a。
每当向计算机发出命令时,它首先要做的一件事情就是“解析”该命令以使其有意义。“语法错误”意味着解析器无法理解所要询问的内容,因为它在语言中未构成有效的命令:换句话说,该命令违反了编程语言的语法。
请务必注意,计算机必须先了解该命令,然后才能对其执行任何操作。由于存在语法错误,MySQL不知道后面是什么,因此在查看数据库之前就放弃了,因此架构或表内容不相关。
显然,需要确定该命令违反MySQL语法的方式。这听起来似乎很难理解,但是MySQL确实在努力为我们提供帮助。我们需要做的就是……
MySQL的不仅告诉我们准确,语法分析器中遇到的语法错误,也使得一个建议用于固定它。例如,考虑以下SQL命令:
UPDATE my_table WHERE id=101 SET name='foo'
该命令产生以下错误消息:
ERROR 1064 (42000): 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 'WHERE id=101 SET name='foo'' at line 1
MySQL告诉我们,一切似乎都可以做到WHERE
,但是随后遇到了问题。换句话说,它并不期望WHERE
在那时遇到。
仅显示消息的...near '' at line...
意思是意外结束了命令的结尾:也就是说,在命令结束之前应该出现其他内容。
程序员通常使用编程语言创建SQL命令。例如,一个php程序可能有这样的(错误)行:
$result = $mysqli->query("UPDATE " . $tablename ."SET name='foo' WHERE id=101");
如果您将此写成两行
$query = "UPDATE " . $tablename ."SET name='foo' WHERE id=101"
$result = $mysqli->query($query);
那么您可以添加echo $query;
或var_dump($query)
查看查询实际是否显示
UPDATE userSET name='foo' WHERE id=101
通常,您会立即看到错误并能够解决。
MySQL还建议我们“检查与我们的MySQL版本相对应的手册以使用正确的语法”。来做吧。
我使用的是MySQL v5.6,因此我将在该版本的手册中输入UPDATE
command。该页面上的第一件事是命令的语法(对于每个命令都是如此):
UPDATE [LOW_PRIORITY] [IGNORE] table_reference
SET col_name1={expr1|DEFAULT} [, col_name2={expr2|DEFAULT}] ...
[WHERE where_condition]
[ORDER BY ...]
[LIMIT row_count]
该手册介绍如何解释下这句法排版和语法约定,但对我们而言这足以认识到:条款包含在方括号中[
和]
是可选的; 竖线|
表示替代方案;和省略号...
表示为简洁起见,或者可以重复前面的条款。
我们已经知道,解析器认为我们命令中的所有内容都可以在WHERE
关键字之前使用,或者换句话说,直到并包括表引用。查看语法,我们看到table_reference
必须在SET
关键字之后:在我们的命令中,实际上是WHERE
关键字。这解释了为什么解析器报告此时遇到了问题。
当然,这是一个简单的例子。但是,通过遵循上面概述的两个步骤(即,准确观察语法分析器在命令中的哪个位置,然后将语法与手册中对该点的预期描述进行比较),几乎可以轻松识别每个语法错误。
我说“几乎所有”,是因为有一小类问题并不十分容易发现,而这就是解析器认为遇到的语言元素意味着一件事,而您却打算意味着另一件事。请看以下示例:
UPDATE my_table SET where='foo'
再次,解析器预计不会WHERE
在这一点上遇到,因此会引发类似的语法错误-但您并不想将其用作where
SQL关键字:您曾打算让它识别要更新的列!但是,如Schema Object Names所述:
如果标识符包含特殊字符或为保留字,则在引用标识符时必须将其引用。(例外:在限定名称中的句点后的保留字必须是标识符,因此不必加引号。)第9.3节“关键字和保留字”中列出了保留字。
[删除]标识符引号是反引号(“
`
”):
mysql> SELECT * FROM `select` WHERE `select`.id > 100;
如果
ANSI_QUOTES
启用了SQL模式,则也可以在双引号中引起标识符的引用:
mysql> CREATE TABLE "test" (col INT); ERROR 1064: You have an error in your SQL syntax... mysql> SET sql_mode='ANSI_QUOTES'; mysql> CREATE TABLE "test" (col INT); Query OK, 0 rows affected (0.00 sec)
KEY
确实是保留字,它出现在我的答案链接到的列表中,位于dev.mysql.com/doc/en/reserved-words.html。这不是错误,其行为是设计使然并有据可查的。您“什么都没有回答”?这篇文章已经是一个完整的答案。
就我而言,我试图在MySQL中执行过程代码,并且由于服务器出现问题,导致服务器无法弄清语句的结束位置,我得到了错误代码1064。因此,我使用自定义DELIMITER和工作正常。
例如,之前是:
DROP PROCEDURE IF EXISTS getStats;
CREATE PROCEDURE `getStats` (param_id INT, param_offset INT, param_startDate datetime, param_endDate datetime)
BEGIN
/*Procedure Code Here*/
END;
放置DELIMITER之后,它是这样的:
DROP PROCEDURE IF EXISTS getStats;
DELIMITER $$
CREATE PROCEDURE `getStats` (param_id INT, param_offset INT, param_startDate datetime, param_endDate datetime)
BEGIN
/*Procedure Code Here*/
END;
$$
DELIMITER ;