1.6如何报告错误或问题

 

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

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

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

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

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

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

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

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

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

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

如果您发现MySQL服务器中存在安全漏洞，请通过向发送电子邮件到，立即通知我们 。例外：支持客户应将所有问题（包括安全性错误）报告给Oracle支持部门，网址为http://support.oracle.com/。 <secalert_us@oracle.com>

要与其他用户讨论问题，可以使用 MySQL Community Slack。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 如果mysqld死亡，则还应报告导致mysqld意外退出的语句。通常，可以通过在启用查询日志记录的情况下运行mysqld，然后在mysqld退出后在日志中查找来获取此信息 。请参见 第5.9节“调试MySQL”。

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

• 问题发生时有效的SQL模式可能很重要，因此请报告sql_mode系统变量的值 。对于存储过程，存储函数和触发器对象，相关sql_mode值是创建对象时生效的值。对于存储过程或函数，SHOW CREATE PROCEDUREor SHOW CREATE FUNCTION语句显示相关的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语句产生的行数 。您还应该包括所涉及的每个表的输出。您提供的有关您情况的信息越多，某人可以帮助您的可能性就越大。 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时发生错误或问题 ，请尝试提供可重现异常的输入脚本。该脚本应包括任何必要的源文件。脚本越能再现您的情况越好。如果可以制作可重现的测试用例，则应上传它以附加到错误报告中。

  如果不能提供脚本，则至少应在报告中包括mysqladmin变量Extended-status processlist的输出，以提供有关系统性能的一些信息。

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

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

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

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

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

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

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

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

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

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

  • 该InnoDB服务器时被杀害后重启，故障恢复机制手柄清理所以在典型的操作没有必要 “ 修复 ”表。如果遇到InnoDB表错误 ，请重新启动服务器，然后查看问题是否仍然存在，或者该错误是否仅影响内存中的缓存数据。如果磁盘上的数据已损坏，请考虑在innodb_force_recovery 启用该选项的情况下重新启动， 以便可以转储受影响的表。

  • 对于非事务处理表，请尝试REPAIR TABLE使用myisamchk或使用 myisamchk对其进行修复 。请参阅 第5章，MySQL服务器管理。

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

• 如果您经常损坏表，则应尝试找出何时以及为什么发生这种情况。在这种情况下，MySQL数据目录中的错误日志可能包含有关所发生情况的一些信息。（这是.err 名称中带有后缀的文件。）请参见第5.4.2节“错误日志”。请在错误报告中包含此文件中的所有相关信息。通常情况下的mysqld应该 永远如果没有杀了它在更新过程中损坏的表。如果您可以找到导致mysqld死的原因 ，那么我们为您提供解决问题的方法会容易得多。看到 第B.3.1节“如何确定导致问题的原因”。

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