为什么 MySQL 语法错误消息如此糟糕？答案

【问题标题】：Why are MySQL syntax error messages so bad?为什么 MySQL 语法错误消息如此糟糕？
【发布时间】：2014-05-08 04:16:52
【问题描述】：

MySQL 语法错误通常很模糊，只指定错误发生的行。编写一个能够产生准确且有用的错误消息的解析器并不是一件容易的事，但它也不是一个开放的研究问题：大多数通用编程语言的编译器都会产生更有用的错误消息。

那么为什么 MySQL 的解析器不能产生更好的错误消息呢？是与 MySQL 相关，还是与一般的 SQL 语法有关？

这是一个例子：

SELECT * FROM foo
WHERE bar > 0
AND baz NOT NULL
ORDER BY qux ASC

MySQL 生成以下错误消息：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 'NULL ORDER BY qux ASC'

其实NOT NULL应该是IS NOT NULL。那么为什么 MySQL 不会产生像 Unexpected token NOT at line 3 column 8 这样的错误呢？

【问题讨论】：

我不是 MySQL 专家，但是一些括号会有帮助吗？ WHERE ((bar>0) AND (baz IS NOT NULL)) ORDER BY qux ASC
MySQL Workbench 5 在此查询中突出显示 NULL 并提供悬停消息 syntax error, unexpected NULL_SYM, expecting BETWEEN_SYM or IN_SYM or LIKE or REGEXP。
有趣，谢谢@AirThomas。在我的例子中，我从 JDBC 中得到了错误消息，但是命令行 MySQL 客户端产生了同样的错误。
我应该澄清一下，尝试在 Workbench 中执行查询会返回您引用的相同错误；只有在编辑器窗口中才能获得更详细的版本。
在我（诚然有限的）经验中，MySQL 的错误消息是我遇到的最清晰的错误消息之一。 100 次中有 99 次错误出现在消息中引用的第一个单词处（或紧邻其左侧）。或者，如果没有显示任何单词，它几乎总是意味着带括号的错误。但是，我确实认为，在引用的第一个词是保留词的情况下，MySQL 应该能够引起我们的注意。

标签： mysql parsing syntax

【解决方案1】：

Oracle 是开源软件走向消亡的地方。他们不愿意让他们的商业数据库应用程序的免费竞争对手变得非常好。暂时没有人会再做一个已经足够好了，现在当我有选择的时候，我更喜欢 MariaDB 和其他分支。

【讨论】：

【解决方案2】：

MySQL Optimizer 优化您发送的查询。当它被执行时，它可能看起来很不一样。此外，在此期间一列的行将保持不变的想法也是不正确的。

下面是 MySQL 如何优化它获得的查询：

http://dev.mysql.com/doc/internals/en/optimizer-primary-optimizations.html

更新 1：

以上是我对错误报告为什么不好的假设。我绝不是说 MySQL 错误报告是好的，它真的很糟糕。有时我会遇到与实际错误完全无关的错误。以下是 Peter Zaitsev 遇到的一些问题（对于使用 MySQL 的人来说，这是一个很棒的博客）：

http://www.mysqlperformanceblog.com/2011/04/06/more-on-mysql-error-messages/ http://www.mysqlperformanceblog.com/2008/03/16/mysql-error-message-nonsenses/

【讨论】：

许多通用编程语言的编译器也执行复杂的优化和转换。解析和报告语法错误早在此之前就发生了。我看不出它与产生好的错误有什么关系。
这并不意味着，在发生错误后，原始查询无法检索，然后由旨在提供更有用的错误消息的解析器进行第二次操作。跨度>
我认为这是 Sun 做出的决定。我同意 MySQL 的错误报告真的很糟糕。你应该看到我以前遇到的错误类型，至少你得到了NULL这句话，它把你带到了某个地方。