1.6如何报告错误或问题

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

  • 通过在搜索的MySQL在线手册开始http://dev.mysql.com/doc/。我们尝试通过对新发现的问题的解决方案进行频繁更新来保持手册的最新状态。此外，手册附带的发行说明可能特别有用，因为较新版本很可能包含您的问题的解决方案。发行说明可在手册中给出的位置上找到。

  • 如果您收到SQL语句的解析错误，请仔细检查您的语法。如果您找不到错误的东西，那么当前版本的MySQL Server极有可能不支持您使用的语法。如果您正在使用当前版本，并且手册不涵盖您使用的语法，则MySQL Server不支持您的语句。

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

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

  • 搜索错误数据库http://bugs.mysql.com/查看是否报告和修复了错误。

  • 在http://lists.mysql.com/上搜索MySQL邮件列表存档。请参见第1.5.1节“MySQL邮件列表”。

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

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

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

发布说明中注明了发布在错误数据库（http://bugs.mysql.com/）中针对给定版本进行了更正的错误。

如果您在MySQL Server中发现敏感的安全漏洞，请通过发送电子邮件通知我们。异常：支持客户应将所有问题（包括安全漏洞）报告给Oracle支持部门，网址为http://support.oracle.com/。<[email protected]>

要与其他用户讨论问题，您可以使用MySQL邮件列表之一。1.5.1节“MySQL邮件列表”。

编写一个很好的错误报告需要耐心，但第一次做正确的事情为我们和自己节省了时间。一个很好的错误报告，包含一个完整的测试用例的错误，使我们很可能在下一个版本中修复错误。本节帮助您正确地撰写报告，以免您的时间浪费时间，这些事情可能无法帮助我们。请仔细阅读本节，并确保此处描述的所有信息都包含在报告中。

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

当问题的良好描述包含在错误报告中时，这是最有帮助的。就是给出一个很好的例子，说明你所做的一切，导致了这个问题，并详细地描述了问题本身。最好的报告是包括一个完整的例子，显示如何重现错误或问题。请参见第24.5节“调试和移植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版本找出运行的版本。该中mysqladmin程序可以在找到bin你的MySQL安装目录下的目录。

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

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

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

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

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

  • 如果mysqld的死了，你也应该报告崩溃的说法mysqld的。您通常可以通过运行mysqld启用查询记录来获取此信息，然后在mysqld崩溃后查看日志。请参见第24.5节“调试和移植MySQL”。

  • 如果数据库表与问题相关，请在错误报告中包含语句的输出。这是一个非常简单的方式来获取数据库中任何表的定义。这些信息有助于我们创造出与您所经历的情况相匹配的情况。SHOW CREATE TABLEdb_name.tbl_name

  • 发生问题的SQL模式有效可以显着，因此请报告sql_mode系统变量的值。对于存储过程，存储函数和触发对象，相关sql_mode值是创建对象时有效的值。对于存储过程或函数，SHOW CREATE PROCEDUREorSHOW 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 TABLEtbl_name

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

    mysql
>
SHOW VARIABLES;

mysql
>

mysql
>

mysql
>

mysql
>

mysql
>
SHOW COLUMNS FROM ...\G
<
output from SHOW COLUMNS
>
EXPLAIN SELECT ...\G
<
output from EXPLAIN
>
FLUSH STATUS;
SELECT ...;
<
A short version of the output from SELECT,

       including the time taken to run the query
>
SHOW STATUS;
<
output from SHOW STATUS
>

  • 如果在运行mysqld时发生错误或问题，请尝试提供一个再现异常的输入脚本。此脚本应包含任何必需的源文件。剧本可以更复杂的情况越好越好。如果你可以做出一个可重现的测试用例，你应该将其上传到bug报告中。

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

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

  • 如果您认为MySQL服务器产生一个声明的奇怪结果，不仅包括结果，还包括您对结果的看法，以及描述您的意见依据的说明。

  • 当您提供问题的一个例子时，最好使用存在于实际情况下的表名，变量名等来提供新名称。该问题可能与表或变量的名称有关。这些情况也许是罕见的，但最好是比安全的抱歉。毕竟，你应该更容易提供一个使用你的实际情况的例子，这对我们来说更是如此。如果您有不想在错误报告中对其他人显示的数据，则可以使用上述“文件”选项卡上传数据。如果这些信息真的是最大的秘密，并且你不想向我们显示这些信息，请继续提供使用其他名称的示例，

  • 如有可能，包括给予相关计划的所有选项。例如，指出启动mysqld服务器时使用的选项以及用于运行任何MySQL客户机程序的选项。程序如mysqld和mysql以及配置脚本的选项通常是解决问题的关键，并且非常重要。将它们包括起来并不是个好主意。如果您的问题涉及使用Perl或PHP等语言编写的程序，请包括语言处理器的版本号以及程序使用的任何模块的版本。例如，DBIDBD::mysqlDBIDBD::mysql

  • 如果您的问题与权限系统相关，请包括mysqladmin reload的输出，以及尝试连接时获取的所有错误消息。当您测试您的权限时，您应该执行mysqladmin重新加载版本，并尝试连接与您的麻烦的程序。

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

    如果我们无法验证补丁的确切目的，我们将不会使用它。测试用例帮助我们在这里。显示修补程序处理可能发生的所有情况。如果我们发现一个边界的情况（甚至是罕见的），补丁将不起作用，那可能是无用的。

  • 猜测bug是什么，为什么会发生，或者依赖什么通常是错误的。即使MySQL团队也不能猜测这样的事情，而不用首先使用调试器来确定错误的真正原因。

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

  • 如果您的数据显示损坏或访问特定表格时出现错误，请先检查表格CHECK TABLE。如果该声明报告任何错误：

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

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

    如果您正在运行Windows，请验证lower_case_table_names使用该SHOW VARIABLES LIKE 'lower_case_table_names'语句的价值。此变量影响服务器如何处理数据库和表名的字母。其对于给定值的影响应如第9.2.2节“识别器大小灵敏度”中所述。

  • 如果您经常遇到损坏的表格，您应该尝试找出发生的时间和原因。在这种情况下，MySQL数据目录中的错误日志可能包含有关发生了什么的一些信息。（这是.err名称后缀的文件。）请参见第5.4.2节“错误日志”。请在您的错误报告中包含此文件的任何相关信息。通常情况下的mysqld应该从来没有崩溃的表，如果没有在更新过程中把它打死了。如果您可以找到mysqld的死因，我们可以为您提供一个解决问题的方法。见B.5.1节“如何确定导致问题的原因”。

  • 如果可能，请下载并安装最新版本的MySQL Server，并检查是否解决您的问题。所有版本的MySQL软件都经过彻底的测试，应该没有问题。我们相信使所有内容尽可能向后兼容，您应该能够毫不费力地切换MySQL版本。请参见第2.1.1节“要安装哪个MySQL版本和分发”。

results matching ""

    No results matching ""