1.7 如何报告错误或问题

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

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

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

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

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

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

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

如果您发现 MySQL 服务器中的安全错误,请通过向<[email protected]>发送电子邮件立即通知我们。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文件来描述您的问题。使用 targzipzip 创建文件的压缩存档。在http://bugs.mysql.com/处为我们的错误数据库启动错误报告后,请单击错误报告中的“文件”选项卡,以获取有关将存档上传到错误数据库的说明。

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

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

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

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

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

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

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

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

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

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

如果您使用的是 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 版本和发行版”