MySQL :: MySQL 9.0 参考手册 :: 1.6 如何报告错误或问题

版本 9.0

8.4 当前
8.0
5.7

8.0 日语

MySQL 9.0 参考手册 / 一般信息 / 如何报告错误或问题

1.6 如何报告错误或问题

在发布有关问题的错误报告之前，请尝试验证它是否是错误，以及是否已报告过。

首先在 MySQL 在线手册中搜索 https://dev.mysqlserver.cn/doc/。我们尝试通过频繁更新手册来保持手册的最新状态，其中包含针对新发现问题的解决方案。此外，随手册提供的发行说明可能特别有用，因为新版本很可能包含对您问题的解决方案。发行说明可在上面提供的手册位置获得。
如果您收到 SQL 语句的解析错误，请仔细检查您的语法。如果您无法找到错误，则很有可能您当前的 MySQL 服务器版本不支持您使用的语法。如果您使用的是当前版本并且手册没有涵盖您使用的语法，则 MySQL 服务器不支持您的语句。
如果手册涵盖了您使用的语法，但您拥有较旧版本的 MySQL 服务器，则应检查 MySQL 更改历史记录以查看何时实施了该语法。在这种情况下，您可以选择升级到更新版本的 MySQL 服务器。
有关一些常见问题的解决方案，请参见第 B.3 节，“问题和常见错误”。
在 http://bugs.mysql.com/ 上搜索错误数据库，以查看该错误是否已报告并修复。
您还可以使用 https://www.mysqlserver.cn/search/ 搜索 MySQL 网站上的所有网页（包括手册）。

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

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

在 http://bugs.mysql.com/ 的错误数据库中发布的错误，如果在特定版本中已修正，将在发行说明中进行说明。

如果您在 MySQL 服务器中发现安全漏洞，请立即通过发送电子邮件到 <[email protected]> 通知我们。例外情况：支持客户应将所有问题（包括安全漏洞）报告给 Oracle 支持 http://support.oracle.com/。

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

编写一份好的错误报告需要耐心，但第一次就写好可以为我们和您节省时间。一份好的错误报告，其中包含错误的完整测试用例，将极大地提高我们在下一个版本中修复错误的可能性。本节将帮助您正确编写报告，以便您不会浪费时间做一些对我们帮助不大甚至毫无帮助的事情。请仔细阅读本节，确保您的报告中包含此处描述的所有信息。

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

在错误报告中包含问题的详细描述非常有帮助。也就是说，提供一个很好的示例，说明您所做的一切导致了问题，并详细描述问题本身。最好的报告是那些包含完整示例以显示如何重现错误或问题的报告。请参见第 7.9 节，“调试 MySQL”。

请记住，我们可能会对包含过多信息的报告做出回复，但不会对包含过少信息的报告做出回复。人们经常省略一些事实，因为他们认为自己知道问题的原因，并假设某些细节无关紧要。一个很好的原则是：如果您对陈述某些内容有疑问，就陈述出来。在您的报告中多写几行比等待更长时间的回复要快且省事，因为我们可能不得不让您提供初始报告中缺少的信息。

错误报告中最常见的错误是 (a) 没有包含您使用的 MySQL 发行版的版本号，以及 (b) 没有完全描述安装 MySQL 服务器的平台（包括平台类型和版本号）。这些是高度相关的关键信息，在 100 个错误报告中，有 99 个报告在没有这些信息的情况下毫无用处。我们经常收到这样的问题：“为什么这对我不起作用？” 然后我们发现，请求的功能在该 MySQL 版本中没有实现，或者报告中描述的错误在更新的 MySQL 版本中已修复。错误通常是平台相关的。在这种情况下，在不知道操作系统和平台的版本号的情况下，我们几乎不可能修复任何问题。

如果您从源代码编译了 MySQL，请记住也要提供有关您的编译器的信息，如果它与问题相关。人们经常在编译器中发现错误，并认为问题与 MySQL 相关。大多数编译器一直在不断开发中，并且随着版本的更新而变得越来越好。为了确定您的问题是否取决于您的编译器，我们需要知道您使用了什么编译器。请注意，每个编译问题都应被视为错误并相应地报告。

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

如果您在使用 Connector/ODBC (MyODBC) 时遇到问题，请尝试生成一个跟踪文件并将其与您的报告一起发送。请参见如何报告 Connector/ODBC 问题或错误。

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

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

您使用的 MySQL 发行版的版本号（例如，MySQL 5.7.10）。您可以通过执行 mysqladmin version 来了解您正在运行哪个版本。该 mysqladmin 程序位于 MySQL 安装目录下的 bin 目录中。
您遇到问题的机器的制造商和型号。
操作系统的名称和版本。如果您使用的是 Windows，您通常可以通过双击“我的电脑”图标并下拉 “帮助/关于 Windows” 菜单来获取名称和版本号。对于大多数类似 Unix 的操作系统，您可以通过执行命令 uname -a 来获取此信息。
有时内存量（实际和虚拟）也很重要。如果有疑问，请包含这些值。
MySQL 安装目录下的 docs/INFO_BIN 文件的内容。该文件包含有关 MySQL 配置和编译方式的信息。
如果您使用的是 MySQL 软件的源代码发行版，请包含您使用的编译器的名称和版本号。如果您有二进制发行版，请包含发行版名称。
如果问题发生在编译期间，请包含确切的错误消息，以及错误发生的文件中出错代码周围的几行上下文。
如果 mysqld 崩溃，您还应该报告导致 mysqld 意外退出的语句。您通常可以通过运行带有查询日志记录功能的 mysqld，然后在 mysqld 退出后查看日志来获取此信息。参见第 7.9 节，“调试 MySQL”。
如果数据库表与问题相关，请在错误报告中包含 SHOW CREATE TABLE db_name.tbl_name 语句的输出。这是一种非常简单的方法来获取数据库中任何表的定义。此信息有助于我们创建一个与您遇到的情况相匹配的情况。
问题发生时生效的 SQL 模式可能很重要，因此请报告 sql_mode 系统变量的值。对于存储过程、存储函数和触发器对象，相关的 sql_mode 值是在创建对象时生效的值。对于存储过程或函数，SHOW CREATE PROCEDURE 或 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 variables extended-status processlist 的输出，以提供有关系统性能的一些信息。
如果您无法仅使用几行数据来创建测试用例，或者测试表太大而无法包含在错误报告中（超过 10 行），您应该使用 mysqldump 导出您的表，并创建一个 README 文件来描述您的问题。使用 tar 和 gzip 或 zip 创建您的文件的压缩存档。在为我们的错误数据库在 http://bugs.mysql.com/ 上启动错误报告后，单击错误报告中的“文件”选项卡，获取有关将存档上传到错误数据库的说明。
如果您认为 MySQL 服务器从语句中产生了奇怪的结果，请不仅包含结果，还要包含您对结果应该是什么的看法，以及描述您观点依据的说明。
当您提供问题的示例时，最好使用表名、变量名等，这些名称存在于您的实际情况中，而不是想出新的名称。问题可能是与表名或变量名有关。这些情况也许很少见，但安全总比后悔好。毕竟，为您提供使用您实际情况的示例会更容易，而且对我们来说绝对是最好的。如果您有不想在错误报告中让其他人看到的数据，可以使用前面描述的“文件”选项卡上传这些数据。如果信息确实是绝密信息，即使您不想让我们看到，也可以继续提供使用其他名称的示例，但请将其视为最后的选择。
如果可能，请包含提供给相关程序的所有选项。例如，指示您启动 mysqld 服务器时使用的选项，以及您用于运行任何 MySQL 客户端程序的选项。对于程序（如 mysqld 和 mysql）以及 configure 脚本的选项，通常是解决问题的关键，并且非常相关。包含它们永远不会是坏事。如果您的问题涉及用 Perl 或 PHP 等语言编写的程序，请包括语言处理器的版本号，以及程序使用的任何模块的版本号。例如，如果您有一个使用 DBI 和 DBD::mysql 模块的 Perl 脚本，请包括 Perl、DBI 和 DBD::mysql 的版本号。
如果您的问题与权限系统有关，请包含 mysqladmin reload 的输出，以及您尝试连接时收到的所有错误消息。当您测试权限时，您应该执行 mysqladmin reload version，并尝试使用让您遇到问题的程序进行连接。
如果您有一个错误补丁，请将其包含进来。但不要假设补丁是我们需要的全部，或者我们可以在没有提供一些必要信息的情况下使用它，例如显示补丁修复的错误的测试用例。我们可能会发现补丁存在问题，或者我们可能根本无法理解它。如果是这样，我们就无法使用它。
如果我们无法验证补丁的确切目的，我们将不会使用它。测试用例在这里很有帮助。表明补丁处理了可能发生的所有情况。如果我们发现补丁无法处理的边界情况（即使是罕见情况），它也可能毫无用处。
关于错误是什么、为什么发生、或它取决于什么等的猜测通常是错误的。即使是 MySQL 团队也无法在不首先使用调试器确定错误的真正原因的情况下猜测这些事情。
在您的错误报告中指出您已检查参考手册和邮件存档，以便其他人知道您已尝试自己解决问题。
如果您的数据看起来已损坏或您在访问特定表时收到错误，请首先使用 CHECK TABLE 检查您的表。如果该语句报告任何错误
- InnoDB 崩溃恢复机制在服务器在被终止后重新启动时处理清理，因此在典型的操作中，没有必要“修复”表。如果您遇到与 InnoDB 表相关的错误，请重新启动服务器并查看问题是否仍然存在，或者错误是否仅影响了内存中的缓存数据。如果磁盘上的数据已损坏，请考虑重新启动并启用 innodb_force_recovery 选项，以便您可以导出受影响的表。
- 对于非事务表，请尝试使用 REPAIR TABLE 或 myisamchk 修复它们。参见第 7 章，MySQL 服务器管理。
如果您正在运行 Windows，请使用 SHOW VARIABLES LIKE 'lower_case_table_names' 语句验证 lower_case_table_names 的值。此变量会影响服务器如何处理数据库和表名的字母大小写。对于给定值，其效果应如第 11.2.3 节，“标识符大小写敏感性” 中所述。
如果您经常遇到损坏的表，您应该尝试找出这种情况发生的时间和原因。在这种情况下，MySQL 数据目录中的错误日志可能包含有关发生情况的一些信息。（这是名称中带有 .err 后缀的文件。）参见第 7.4.2 节，“错误日志”。请在您的错误报告中包含来自此文件的任何相关信息。通常情况下，mysqld 应该绝不损坏表，除非在更新过程中有东西终止了它。如果您能找到 mysqld 崩溃的原因，我们就能更容易地为您提供问题的解决方案。参见第 B.3.1 节，“如何确定导致问题的原因”。
如果可能，请下载并安装最新版本的 MySQL Server，并检查它是否解决了您的问题。所有版本的 MySQL 软件都经过了彻底的测试，应该可以正常工作。我们相信尽可能地保持向后兼容性，您应该能够在不困难的情况下切换 MySQL 版本。参见第 2.1.2 节，“安装哪个 MySQL 版本和发行版”。

PREV HOME UP NEXT