# 1.6 如何报告错误或问题

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

  • 首先在以下位置搜索 MySQL 在线手册https://dev.mysql.com/doc/ (opens new window).我们试图通过经常更新手册以解决新发现的问题来保持手册的最新状态。此外,手册随附的发行说明可能特别有用,因为较新的版本很可能包含您的问题的解决方案。发行说明可在刚刚为手册指定的位置找到。

  • 如果您收到一条 SQL 语句的解析错误,请仔细检查您的语法。如果你找不到它有什么问题,很可能是你当前版本的 MySQL 服务器不支持你正在使用的语法。如果您使用的是当前版本并且手册未涵盖您使用的语法,则 MySQL Server 不支持您的语句。

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

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

  • 在错误数据库中搜索http://bugs.mysql.com/ (opens new window)查看该错误是否已被报告和修复。

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

    如果您在手册、错误数据库或邮件列表档案中找不到答案,请咨询您当地的 MySQL 专家。如果您仍然无法找到问题的答案,请使用以下指南报告错误。

    报告错误的正常方法是访问http://bugs.mysql.com/ (opens new window),这是我们的错误数据库的地址。该数据库是公开的,任何人都可以浏览和搜索。如果您登录到系统,您可以输入新的报告。

    在错误数据库中发布的错误http://bugs.mysql.com/ (opens new window)对给定版本进行了更正的版本在发行说明中注明。

    如果您在 MySQL Server 中发现安全漏洞,请立即发送电子邮件至<[secalert_us@oracle.com](mailto:secalert_us@oracle.com)>.例外:支持客户应向 Oracle 支持报告所有问题,包括安全漏洞,网址为http://support.oracle.com/ (opens new window).

    要与其他用户讨论问题,您可以使用MySQL 社区松弛 (opens new window).

    写一份好的bug报告需要耐心,但第一次就做好会为我们和你自己节省时间。一份好的bug报告,包含bug的完整测试用例,使我们很有可能在下一个版本中修复bug。本节帮助您正确编写报告,这样您就不会浪费时间做可能对我们帮助不大或根本没有帮助的事情。请仔细阅读本节,并确保您的报告中包含此处描述的所有信息。

    在发布之前,最好使用最新的MySQL Server生产或开发版本测试问题。任何人只要使用mysql测试<script_文件在测试用例上,或者通过运行包含在错误报告中的shell或Perl脚本。我们能够重复的任何错误都有很高的几率在下一个MySQL版本中得到修复。

    当错误报告中包含对问题的良好描述时,它会非常有用。也就是说,举一个好例子,说明你所做的一切导致了问题,并详细描述问题本身。最好的报告包括一个完整的例子,说明如何重现错误或问题。看见第5.9节,“调试MySQL”.

    记住,我们可以对包含太多信息的报告做出回应,但不能对包含太少信息的报告做出回应。人们往往忽略事实,因为他们认为自己知道问题的原因,并认为一些细节无关紧要。要遵循的一个好原则是,如果你对陈述某事有疑问,就陈述它。如果我们必须要求您提供初始报告中缺失的信息,那么在报告中多写几行比等待答案的时间更长更快、更省事。

    错误报告中最常见的错误是(a)没有包括您使用的MySQL发行版的版本号,以及(b)没有完整描述安装MySQL服务器的平台(包括平台类型和版本号)。这些都是高度相关的信息,在100个案例中,有99个案例没有它们,错误报告就毫无用处。我们经常会遇到这样的问题:“为什么这对我不管用?”然后,我们发现请求的功能没有在该MySQL版本中实现,或者报告中描述的错误已在较新的MySQL版本中修复。错误通常取决于平台。在这种情况下,我们几乎不可能在不知道操作系统和平台版本号的情况下修复任何东西。

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

    如果程序生成错误消息,则在报告中包含该消息非常重要。如果我们试图从档案中搜索某些内容,那么报告的错误消息最好与程序生成的消息完全匹配。(即使是信笺也要注意。)最好将整个错误消息复制并粘贴到报告中。你不应该试图从记忆中重现信息。

    如果您对Connector/ODBC(MyODBC)有问题,请尝试生成跟踪文件并将其与报告一起发送。看见如何报告连接器/ODBC问题或错误 (opens new window).

    如果您的报告包含来自您运行的测试用例的长查询输出行mysql命令行工具,通过使用--垂直的选项还是\G声明终结者。这个解释选择本节后面的示例演示了\G.

    请在您的报告中包含以下信息:

  • 您正在使用的MySQL发行版的版本号(例如,MySQL 5.7.10)。您可以通过执行mysqladmin版本这个mysqladmin程序可以在箱子MySQL安装目录下的目录。

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

  • 操作系统名称和版本。如果您使用Windows,通常可以通过双击“我的电脑”图标并下拉“帮助/关于Windows”菜单来获取名称和版本号。对于大多数类似Unix的操作系统,您可以通过执行命令来获取这些信息找到对应内核版本.

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

  • 文件的内容文档/信息库来自MySQL安装的文件。该文件包含有关MySQL如何配置和编译的信息。

  • 如果您使用的是MySQL软件的源代码发行版,请提供所用编译器的名称和版本号。如果有二进制发行版,请包含发行版名称。

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

  • 如果mysqld如果你死了,你也应该报告mysqld出人意料地退出。您通常可以通过运行mysqld启用查询日志记录,然后在mysqld出口。看见第5.9节,“调试MySQL”.

  • 如果数据库表与问题有关,请包括显示创建表*db_名称*.*tbl_名称*错误报告中的声明。这是获取数据库中任何表的定义的一种非常简单的方法。这些信息有助于我们创建一个与您所经历的情况相匹配的情况。

  • 问题发生时有效的SQL模式可能非常重要,因此请报告sql_模式系统变量。对于存储过程、存储函数和触发器对象sql_模式值是创建对象时生效的值。对于存储过程或函数显示创建过程显示创建功能语句显示相关的SQL模式,也可以进行查询信息模式有关信息:

    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;
    
  • 与性能相关的错误或问题选择语句中,应该始终包含解释选择。。。,以及至少选择语句生成。您还应该包括显示创建表*tbl_名称*对于涉及的每个表。你提供的关于你的情况的信息越多,就越有可能有人能帮助你。

    下面是一个非常好的bug报告示例。这些语句是使用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变量扩展状态进程列表在您的报告中提供一些有关系统运行情况的信息。

  • 如果您无法生成只有几行的测试用例,或者如果测试表太大,无法包含在错误报告中(超过10行),那么应该使用mysqldump创造一个自述描述您的问题的文件。使用焦油gzip拉链.在你为我们的错误数据库在http://bugs.mysql.com/ (opens new window),单击bug报告中的“文件”选项卡,获取有关将归档文件上载到bug数据库的说明。

  • 如果您认为MySQL服务器从一条语句中产生了一个奇怪的结果,那么不仅要包括结果,还要包括您对结果应该是什么的看法,以及描述您观点基础的解释。

  • 当您提供问题的示例时,最好使用实际情况中存在的表名、变量名等,而不是使用新名称。问题可能与表或变量的名称有关。这些病例可能很少见,但与其说抱歉,不如说安全。毕竟,你应该更容易提供一个使用你的实际情况的例子,这对我们来说绝对是更好的。如果您在bug报告中有不希望他人看到的数据,可以使用前面描述的“文件”选项卡上载。如果这些信息真的是绝密信息,你甚至不想把它展示给我们,那就用其他名字来举例吧,但请把这当作最后的选择。

  • 如果可能的话,包括相关项目的所有选项。例如,请指明启动应用程序时使用的选项mysqld服务器,以及用于运行任何MySQL客户端程序的选项。这些项目的选项包括:mysqldmysql,以及配置脚本通常是解决问题的关键,并且非常相关。把它们包括进来从来都不是一个坏主意。如果您的问题涉及用Perl或PHP等语言编写的程序,请包括语言处理器的版本号,以及该程序使用的任何模块的版本。例如,如果您有一个使用DBIDBD::mysql模块,包括Perl的版本号,DBIDBD::mysql.

  • 如果您的问题与特权系统有关,请包括mysqladmin重新加载,以及尝试连接时收到的所有错误消息。当你测试你的特权时,你应该执行mysqladmin重新加载版本试着联系给你带来麻烦的程序。

  • 如果你有一个bug补丁,一定要包括它。但是,如果您没有提供一些必要的信息,例如显示修补程序修复的错误的测试用例,请不要假设修补程序就是我们所需要的,或者我们可以使用它。我们可能会发现你的补丁有问题,或者根本不理解。如果是这样,我们就不能使用它。

    如果我们无法验证补丁的确切用途,我们将不会使用它。测试用例在这里帮助我们。显示补丁可以处理所有可能发生的情况。如果我们发现一个边缘病例(即使是罕见病例)补丁无法工作,它可能是无用的。

  • 对错误是什么、发生原因或它依赖于什么的猜测通常是错误的。即使是MySQL团队,如果不先使用调试器来确定错误的真正原因,也无法猜到这些事情。

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

  • 如果在访问特定表时数据损坏或出现错误,请首先使用检查表.如果该声明报告了任何错误:

    • 这个InnoDB崩溃恢复机制在服务器被终止后重新启动时处理清理,因此在典型操作中不需要“修复”表。如果你遇到错误InnoDB表,重新启动服务器,查看问题是否仍然存在,或者错误是否仅影响内存中的缓存数据。如果磁盘上的数据损坏,请考虑重新启动innodb_force_recovery选项已启用,以便可以转储受影响的表。

    • 对于非事务性表,请尝试使用修理台或者myisamchk看见第五章,MySQL服务器管理.

      如果您正在运行Windows,请验证小写字母表名称使用显示“小写字母表名”等变量陈述此变量影响服务器处理数据库和表名的大小写的方式。其对给定值的影响应如中所述第9.2.3节,“标识符区分大小写”.

  • 如果您经常得到损坏的表,您应该尝试找出发生这种情况的时间和原因。在这种情况下,MySQL数据目录中的错误日志可能包含一些关于发生了什么的信息。(这是带有犯错误名称中的后缀。)看见第5.4.2节“错误日志”。请在错误报告中包含此文件中的任何相关信息。正常地mysqld应该从不如果在更新过程中没有任何事件损坏表,则损坏该表。如果你能找到mysqld临终前,我们更容易为您提供问题的解决方案。看见第B.3.1节,“如何确定导致问题的原因”.

  • 如果可能的话,下载并安装最新版本的MySQL服务器,并检查它是否解决了您的问题。MySQL软件的所有版本都经过彻底测试,应该可以正常工作。我们相信让一切尽可能向后兼容,你应该能够毫不费力地切换MySQL版本。看见第2.1.2节,“要安装哪个MySQL版本和发行版”.