1.7 如何报告错误或问题

在发布有关问题的错误报告之前，请尝试确认它是错误并且尚未报告：

• 首先在https://dev.mysql.com/doc/搜索 MySQL 在线手册。我们试图通过不断更新手册来解决最新发现的问题，从而使手册保持最新。此外，手册随附的发行说明可能特别有用，因为更新的版本很可能包含解决您的问题的方法。发行说明可在手册指定的位置获得。

• 如果您收到 SQL 语句的解析错误，请仔细检查语法。如果找不到错误，很可能是您当前的 MySQL Server 版本不支持您使用的语法。如果您使用的是当前版本，并且手册未涵盖所使用的语法，则 MySQL Server 不支持您的声明。

如果手册涵盖了您正在使用的语法，但是您使用的是 MySQL Server 的较旧版本，则应查看 MySQL 更改历史记录以了解何时实施了语法。在这种情况下，您可以选择升级到较新版本的 MySQL Server。

• 有关一些常见问题的解决方案，请参见第 B.4 节“问题和常见错误”。

• 在http://bugs.mysql.com/处搜索错误数据库，以查看是否已报告并修复了该错误。

• 您也可以使用http://www.mysql.com/search/搜索位于 MySQL 网站上的所有网页(包括手册)。

如果在手册，错误数据库或邮件列 tableFiles 中找不到答案，请与当地的 MySQLmaven 联系。如果仍然找不到问题的答案，请使用以下准则报告该错误。

报告错误的常规方法是访问http://bugs.mysql.com/，这是我们的错误数据库的地址。该数据库是公共的，任何人都可以浏览和搜索。如果登录到系统，则可以 Importing 新报告。

在发行说明中记录了在错误数据库http://bugs.mysql.com/中发布的，针对给定发行版已更正的错误。

如果您发现 MySQL 服务器中的安全错误，请通过向<secalert_us@oracle.com>发送电子邮件立即通知我们。exception：支持 Client 应通过http://support.oracle.com/向 Oracle 支持部门报告所有问题，包括安全错误。

要与其他用户讨论问题，可以使用MySQL 社区松弛。

编写好的错误报告需要耐心，但是第一次正确地执行报告可以为我们和您自己节省时间。一个好的 bug 报告，其中包含该 bug 的完整测试用例，使得我们很可能在下一版本中修复该 bug。本部分可帮助您正确编写报告，以免浪费时间去做对我们没有多大帮助或根本没有帮助的事情。请仔细阅读本节，并确保报告中包含此处描述的所有信息。

最好在发布之前，使用 MySQL Server 的最新生产或开发版本测试问题。任何人都可以通过在测试用例上使用mysql test < script_file或运行错误报告中包含的 shell 或 Perl 脚本来重复该错误。我们能够重复的任何错误都很有可能在下一个 MySQL 版本中得到修复。

当错误报告中包含对问题的良好描述时，这将非常有帮助。也就是说，举一个很好的例子说明导致问题的所有操作，并详细描述问题本身。最好的报告是那些包含完整示例的示例，这些示例说明了如何重现该错误或问题。参见第 28.5 节“调试和移植 MySQL”。

请记住，我们可能对包含太多信息的报告做出回应，而对包含太少信息的报告做出回应。人们经常忽略事实，因为他们认为他们知道问题的原因，并认为某些细节无关紧要。遵循的一个很好的原则是，如果您不确定要说些什么，请说明。如果我们必须要求您提供初始报告中缺少的信息，则在报告中多写几行比 await 更长的答案要更快，更麻烦。

错误报告中最常见的错误是(a)不包括您使用的 MySQL 发行版的版本号，以及(b)不完整描述安装 MySQL 服务器的平台(包括平台类型和版本号) 。这些是高度相关的信息，在没有这些情况的情况下，有 100 个案例中有 99 个案例是无效的。很多时候，我们会收到诸如“为什么这对我不起作用？”之类的问题。然后，我们发现请求的功能未在该 MySQL 版本中实现，或者报告中描述的错误已在较新的 MySQL 版本中修复。错误通常取决于平台。在这种情况下，我们几乎不可能在不知道 os 和平台版本号的情况下进行任何修复。

如果您是从源代码编译的 MySQL，请记住，如果与问题有关，还应提供有关编译器的信息。人们通常会在编译器中发现错误，并认为问题与 MySQL 有关。大多数编译器一直在开发中，并且每个版本都变得更好。为了确定您的问题是否取决于您的编译器，我们需要知道您使用的编译器。请注意，每个编译问题都应视为错误，并进行相应报告。

如果程序产生错误消息，将错误消息包含在报告中非常重要。如果我们尝试从 Files 中搜索内容，则最好报告的错误消息与程序产生的错误消息完全匹配。 (甚至应注意字母大小写.)最好将整个错误消息复制并粘贴到您的报告中。您永远不要尝试从内存中重现消息。

如果连接器/ ODBC(MyODBC)有问题，请尝试生成跟踪文件并将其与报告一起发送。参见如何报告连接器/ ODBC 问题或错误。

如果您的报告中包含使用mysql命令行工具运行的测试用例中的较长查询输出行，则可以使用--vertical选项或\G语句终止符使输出更具可读性。本节后面的EXPLAIN SELECT示例演示了\G的用法。

请在报告中包括以下信息：

• 您正在使用的 MySQL 发行版的版本号(例如，MySQL 5.7.10)。您可以通过执行mysqladmin version找出正在运行的版本。可以在 MySQL 安装目录下的bin目录中找到mysqladmin程序。

• 您遇到问题的机器的制造商和型号。

• os 名称和版本。如果使用 Windows，通常可以通过双击“我的电脑”图标并下拉“帮助/关于 Windows”菜单来获得名称和版本号。对于大多数类 Unixos，您可以通过执行命令uname -a获得此信息。

• 有时(实际和虚拟)内存量是相关的。如有疑问，请包括这些值。

• MySQL 安装中的docs/INFO_BIN文件的内容。该文件包含有关如何配置和编译 MySQL 的信息。

• 如果您使用的是 MySQL 软件的源发行版，请包括您使用的编译器的名称和版本号。如果您有二进制发行版，请包括发行版名称。

• 如果在编译过程中出现问题，请在发生错误的文件中包含确切的错误消息，以及在有问题的代码周围的几行上下文。

• 如果mysqld死亡，则还应报告崩溃了mysqld的语句。通常，可以通过在启用查询日志记录的情况下运行mysqld并在mysqld崩溃后查看日志来获取此信息。参见第 28.5 节“调试和移植 MySQL”。

• 如果数据库 table 与问题有关，请将SHOW CREATE TABLE db_name.tbl_name语句的输出包括在错误报告中。这是获取数据库中任何 table 的定义的一种非常简单的方法。这些信息可帮助我们创建与您所经历的情况相匹配的情况。

• 问题发生时有效的 SQL 模式可能很重要，因此请报告sql_mode系统变量的值。对于存储过程，存储函数和触发器对象，相关的sql_mode值是创建对象时生效的值。对于存储过程或函数，显示创建步骤或显示创建功能语句显示相关的 SQL 模式，或者您可以查询INFORMATION_SCHEMA以获得以下信息：

SELECT ROUTINE_SCHEMA, ROUTINE_NAME, SQL_MODE
FROM INFORMATION_SCHEMA.ROUTINES;

对于触发器，可以使用以下语句：

SELECT EVENT_OBJECT_SCHEMA, EVENT_OBJECT_TABLE, TRIGGER_NAME, SQL_MODE
FROM INFORMATION_SCHEMA.TRIGGERS;

• 对于与性能相关的错误或SELECT语句的问题，您应始终包括EXPLAIN SELECT ...的输出，至少包括SELECT语句产生的行数。您还应该为每个涉及的 table 包括SHOW CREATE TABLE tbl_name的输出。您提供的有关您情况的信息越多，某人可以帮助您的可能性就越大。

以下是一个非常好的错误报告的示例。该语句使用mysql命令行工具运行。请注意，将\G语句终止符用于否则将提供很难阅读的非常长的输出行的语句。

mysql> SHOW VARIABLES;
mysql> SHOW COLUMNS FROM ...\G
       <output from SHOW COLUMNS>
mysql> EXPLAIN SELECT ...\G
       <output from EXPLAIN>
mysql> FLUSH STATUS;
mysql> SELECT ...;
       <A short version of the output from SELECT,
       including the time taken to run the query>
mysql> SHOW STATUS;
       <output from SHOW STATUS>

• 如果在运行mysqld时发生错误或问题，请尝试提供可重现异常的 Importing 脚本。该脚本应包括任何必要的源文件。脚本越能再现您的情况越好。如果可以制作可重现的测试用例，则应上传它以附加到错误报告中。

如果无法提供脚本，则至少应在报告中包含mysqladmin 变量扩展状态进程列 table的输出，以提供有关系统性能的一些信息。

• 如果您无法生成仅包含几行的测试用例，或者测试 table 太大而无法包含在错误报告中(超过 10 行)，则应使用mysqldump转储 table 并创建一个README文件来描述您的问题。使用 tar 和 gzip 或 zip 创建文件的压缩存档。在http://bugs.mysql.com/处为我们的错误数据库启动错误报告后，请单击错误报告中的“文件”选项卡，以获取有关将存档上传到错误数据库的说明。

• 如果您认为 MySQL 服务器从一条语句中得出了奇怪的结果，则不仅要包括结果，还应包括对结果的看法，以及说明观点基础的解释。

• 当您提供问题的示例时，最好使用实际情况中存在的 table 名，变量名等，而不是使用新名称。该问题可能与 table 或变量的名称有关。这些情况也许很少见，但是安全起着总比后悔好。毕竟，为您提供一个使用您的实际情况的示例应该更容易，并且这对我们来说绝对是更好的选择。如果您有不想让其他人在错误报告中看到的数据，则可以使用“文件”选项卡将其上传，如前所述。如果该信息确实是最高机密的，并且您甚至不想向我们展示该信息，请 continue 使用其他名称提供示例，但请将此作为最后的选择。

• 如果可能，包括提供给相关程序的所有选项。例如，指定启动mysqld服务器时使用的选项以及用于运行任何 MySQLClient 端程序的选项。诸如mysqld和mysql之类的程序以及 configure 脚本的选项通常是解决问题的关键，并且非常相关。包含它们永远不是一个坏主意。如果您的问题涉及使用 Perl 或 PHP 等语言编写的程序，请提供语言处理器的版本号，以及该程序使用的任何模块的版本。例如，如果您有一个使用DBI和DBD::mysql模块的 Perl 脚本，请包括 Perl，DBI和DBD::mysql的版本号。

• 如果您的问题与特权系统有关，请包括mysqladmin reload的输出，以及尝试连接时收到的所有错误消息。在测试特权时，应执行mysqladmin 重装版本并尝试连接给您带来麻烦的程序。

• 如果您有漏洞的补丁程序，请务必将其包含在内。但是，如果您没有提供一些必要的信息(例如，测试用例显示补丁已修复的错误)，则不要以为补丁是我们所需要的或可以使用的补丁。我们可能会发现您的补丁有问题，或者可能根本不了解。如果是这样，我们将无法使用它。

如果我们无法验证补丁的确切目的，我们将不会使用它。测试用例在这里对我们有帮助。证明该补丁程序可以处理所有可能发生的情况。如果我们发现补丁无法正常工作的极端情况(即使是极少数的情况)，则可能毫无用处。

• 猜测错误是什么，原因为何或依赖于什么通常是错误的。甚至 MySQL 团队也无法在没有先使用调试器确定错误的 true 原因的情况下猜测此类事情。

• 在错误报告中指出您已经检查了参考手册和邮件归档，以便其他人知道您已尝试自己解决问题。

• 如果访问特定 table 时数据看起来已损坏或出现错误，请首先使用CHECK TABLE检查 table。如果该语句报告任何错误：

• 当服务器被杀死后，重新启动时，InnoDB崩溃恢复机制将处理清理，因此在典型操作中，无需“修复”table。如果InnoDBtable 遇到错误，请重新启动服务器，然后查看问题是否仍然存在，或者该错误是否仅影响内存中的缓存数据。如果磁盘上的数据已损坏，请考虑在启用innodb_force_recovery选项的情况下重新启动，以便转储受影响的 table。

  • 对于非事务处理 table，请尝试使用REPAIR TABLE或myisamchk修复它们。参见第 5 章，MySQL 服务器 Management。

如果您使用的是 Windows，请使用SHOW VARIABLES LIKE 'lower_case_table_names'语句验证lower_case_table_names的值。此变量影响服务器处理数据库名称和 table 名称的字母大小写的方式。给定值的效果应如第 9.2.3 节“标识符区分大小写”中所述。

• 如果您经常损坏 table，则应尝试找出何时以及为什么发生这种情况。在这种情况下，MySQL 数据目录中的错误日志可能包含有关所发生情况的一些信息。 (这是后缀为.err的文件.)请参阅第 5.4.2 节“错误日志”。请在错误报告中包含此文件中的所有相关信息。通常mysqld应该*绝不要使 table 崩溃，如果在更新过程中没有任何杀死它的 table。如果您找到mysqld死亡的原因，那么我们可以很轻松地为您提供解决问题的方法。参见第 B.4.1 节“如何确定导致问题的原因”。

• 如果可能，请下载并安装最新版本的 MySQL Server，然后检查它是否可以解决您的问题。 MySQL 软件的所有版本都经过全面测试，应该可以正常工作。我们相信要使所有内容都向后兼容，并且您应该能够轻松切换 MySQL 版本。参见第 2.1.1 节“要安装哪个 MySQL 版本和发行版”。