没有一种合适的方式来捕捉和诊断 MySQL 服务器端的错误，因此想知道什么地方出错了基本上是不可能的。

我们使用下面这样一个查询来证明这个结论：

这个查询可能发生什么错误？

违反 UNIQUE KEY 约束
违反 FOREIGN KEY 约束
my_column 字段类型可能是 TINYINT UNSIGNED, 而严格的 sql_mode 导致数值越界
后者字段类型可能是某个枚举，如 ENUM (2,3,5,8)
还有可能是这样一些错误：

my_table 可能是一个只读的 MyISAM 表
我们对 my_table 进行了锁表操作 LOCK TABLES my_table READ -- 违反了锁
或者可能是一个 InnoDB 表，而 INSERT 可能导致死锁
配置了 read_only=1 只读
或者用户没法访问该表的权限
或者表不存在
也有可能是字段不存在
而且我还确定还可能有更多的错误原因存在。

现在，如果我写了一个 Java 程序，可能用了 Hibernate，那么我将会通过 SQLException 得到一个描述比较清晰的异常信息，我可以得知错误码和错误信息。

但在 MySQL 的服务器端，例如是存储过程呢？则不行！
再看看下面的代码：

如果我们希望为指定的错误执行相应的动作，我们需要：

但如果我们比知道将会发生什么错误，但仍希望记录这个错误，这样我们可能需要定义成百上千的 HANDLERs，尽管如此还是无法覆盖所有的错误情况。

5.5 版本不是引入了 SINGAL 和 RESIGNAL 了吗？
是的，的确是引入了，但对你毫无帮助，你可以重新 RESIGNAL 一个错误，但并不意味着错误实际发生时你能知晓。

那么，问题是什么呢？
我想在服务器端做很多事情，而不是通过外部脚本如 Python/Perl/Java/Ruby/Shell 等，例如 event scheduler: 我的意思是有什么意义呢？如果在服务器端很多事情你没法做的话，那将是无用的。你不能够组织错误，不能得到足够的错误描述信息，这只不过是你想执行好工作的一小部分而已。

在 common_schema/QueryScript 中我提供了一些脚本，但错误处理该怎么办呢？我编写了一个完全不同的错误处理方法（尚未发布），但一旦在服务器端运行 common_schema , 因为服务器的限制导致其功能是有限的，也就是说用处的确很小。

本来不错
这是 error_count 连接会话变量，实际上也没有任何用途，有了下面两个变量就会好很多：

如果一个查询导致了多个错误，请选择其中一个。

或者使用其他方法来在服务器端解析 SHOW 命令(参考 这里). 如果我可以解析 SHOW ERRORS 命令，那么所有事情都能得以解决。

MySQL 5.0 引入了 INFORMATION_SCHEMA, 虽然并不完整。很快 SHOW 命令被排除在服务器端游标之外。因为太多的功能缺失，所以我提交了一个 bug report/feature request. 你支持我吗？

译者注：后面内容翻译的很糟糕，完全不知道在说什么，如果费劲请看英文原文或者共同翻译下。

英文原文，OSCHINA原创翻译

--转自