扩展 MySQL 8.0  / 第一章简介  /  1.6 如何报告错误或问题

1.6 如何报告错误或问题

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

  • 首先在 https://mysql.net.cn/doc/上搜索 MySQL 在线手册。我们通过经常更新新发现问题的解决方案来努力使手册保持最新状态。此外,手册随附的发行说明可能特别有用,因为较新的版本很可能包含针对您的问题的解决方案。发行说明可在刚刚为手册指定的位置获得。

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

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

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

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

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

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

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

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

如果您在 MySQL 服务器中发现安全漏洞,请立即发送电子邮件至 告知我们 。例外:支持客户应将所有问题(包括安全漏洞)报告给 Oracle 支持,网址为http://support.oracle.com/

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

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

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

当错误报告中包含对问题的良好描述时,这是最有帮助的。也就是说,举一个很好的例子说明你所做的导致问题的一切,并详细描述问题本身。最好的报告是那些包含一个完整示例的报告,该示例显示了如何重现错误或问题。参见 第 5.8 节,“调试 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程序可以在 MySQL bin安装目录下的目录中找到。

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

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

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

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

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

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

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

  • 如果数据库表与问题相关,请在错误报告中 包含该语句的输出。这是获取数据库中任何表的定义的一种非常简单的方法。这些信息帮助我们创造一种与您所经历的情况相匹配的情况。 SHOW CREATE TABLE db_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 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 变量扩展状态进程列表的输出,以提供有关系统执行情况的一些信息。

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

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

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

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

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

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

    如果我们无法验证补丁的确切用途,我们将不会使用它。测试用例在这里帮助我们。显示补丁处理所有可能发生的情况。如果我们发现补丁不起作用的临界情况(即使是罕见的情况),它可能就没用了。

  • 对 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.3 节“标识符区分大小写”中所述。

  • 如果您经常遇到损坏的表,您应该尝试找出发生这种情况的时间和原因。在这种情况下,MySQL 数据目录中的错误日志可能包含有关所发生情况的一些信息。(这是.err 名称中带有后缀的文件。)请参阅第 5.4.2 节,“错误日志”。请在您的错误报告中包含此文件中的任何相关信息。通常mysqld应该 永远不会破坏一个表,如果在更新过程中没有任何东西杀死它的话。如果您能找到 mysqld死机的原因,我们就可以更轻松地为您提供问题的修复程序。看 第 B.3.1 节,“如何确定导致问题的原因”

  • 如果可能,请下载并安装最新版本的 MySQL 服务器并检查它是否能解决您的问题。所有版本的 MySQL 软件都经过全面测试,应该可以正常工作。我们相信让一切都尽可能向后兼容,你应该能够毫无困难地切换 MySQL 版本。请参阅 第 2.1.2 节,“安装哪个 MySQL 版本和发行版”