MySql 中文参考指南

1.6 How to Report Bugs or Problems

在提交有关某个问题的错误报告之前，请先尝试验证它是一个错误，并且之前没有报告过：

  1. 首先使用 [role="bare"]https://dev.mysql.com/doc/ 在 MySQL 在线手册中搜索。我们尝试经常更新手册以提供新发现问题的解决方案，从而使手册保持最新。此外，手册附带的发行说明可能特别有用，因为较新版本中很可能包含解决问题的办法。发行说明与手册中给出的位置相同。

  2. 如果 SQL 语句出现解析错误，请仔细检查语法。如果找不到错误，则极有可能是你当前使用的 MySQL Server 版本不支持你所使用的语法。如果你使用的是当前版本且手册中没有介绍所使用的语法，则 MySQL Server 并不支持该语句。

如果手册中包含你正在使用的语法，但你所使用的 MySQL Server 版本较旧，则你应检查 MySQL 更改历史记录以查看何时实施语法。在这种情况下，可以选择升级到较新版本的 MySQL Server。

  1. 有关一些常见问题的解决方案，请参见 ` Section B.3, “Problems and Common Errors”` 。

  2. 在 ` http://bugs.mysql.com/` 中搜索 Bug 数据库以查看 Bug 是否已被报告并修复。

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

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

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

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

如果您在 MySQL Server 中发现了一个安全漏洞，请发送一封电子邮件至 < link:mailto:secalert_us@oracle.com[secalert_us@oracle.com]> ，立即告知我们。例外情况：支持客户应将所有问题（包括安全漏洞）报告给 http://support.oracle.com/ 的 Oracle 支持服务。

  1. 要与其他用户讨论问题，可以使用 MySQL Community Slack。

编写一份好的缺陷报告需要耐心，但从一开始就正确地完成它可以为您和我们节省时间。一份好的缺陷报告应包含该缺陷的完整测试用例，它很可能使我们在下个版本中修复该缺陷。本部分将帮助您正确撰写您的报告，这样您就可以避免浪费时间去做对我们帮助不大或完全没帮助的事情。请仔细阅读本部分，并确保报告中包含此处描述的所有信息。

您最好使用 MySQL 服务器的最新生产版本或开发版本测试问题，然后再发布。任何人都应该可以通过 mysql test < script_file 上的测试用例或通过运行缺陷报告中包含的 shell 或 Perl 脚本来重复该缺陷。我们能够重复出现的任何缺陷都有很大机会在下一个 MySQL 版本中修复。

  1. 在错误报告中包含对问题进行很好的描述将很有帮助。也就是说，举一个导致问题的所做一切的例子，并准确详细地描述问题本身。最好的报告是包含一个完整的示例，说明如何重现错误或问题。参见 Section 7.9, “Debugging MySQL”。

请记住，对于包含过多信息的报告，我们有可能做出响应，但对于包含过少信息的报告，我们不可能做出响应。人们经常省略事实，因为他们认为自己知道问题的起因，并假设某些细节无关紧要。需要遵循的一个好原则是，如果您对陈述某事犹豫不决，请陈述出来。在报告中多写几行比在我们需要要求您提供初始报告中缺少的信息时较长时间等待答案更快速且不那么麻烦。

在 bug 报告中常见的错误是：(a) 没有包括你所用的 MySQL 发行版的版本号，以及 (b) 没有完整描述安装了 MySQL 服务器的平台（包括平台类型和版本号）。这些是非常重要的信息，在 100 个中有 99 次，没有它们，bug 报告都是没用的。许多时候，我们会收到这样的问题：“为什么这个功能对我不起作用？”然后我们发现该请求的功能并未在该 MySQL 版本中实现，或者报告中描述的 bug 已在较新版本中修复。错误通常与平台相关。在这种情况下，如果没有操作系统和平台的版本号，我们几乎不可能修复任何内容。

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

如果一个程序产生了一个错误消息，则在报告中包含这个消息非常重要。如果我们尝试从存档中搜索一些东西，那么报告的错误消息与程序产生的错误消息完全匹配会更好。（即使是大小写也应注意。）最好将完整的错误消息复制并粘贴到你的报告中。你永远不应该尝试从内存中复制该消息。

  1. 如果你在 Connector/ODBC (MyODBC) 中遇到问题，请尝试生成一个跟踪文件并随报告一起发送。参见 How to Report Connector/ODBC Problems or Bugs。

如果您的报告包括使用 mysql 命令行工具运行的测试用例中的长查询输出行，您可以通过使用 —​vertical 选项或 \G 语句终止符使输出更具可读性。本节后文中的 EXPLAIN SELECT 实例演示了如何使用 \G 。

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

  1. 您正在使用的 MySQL 发行版的版本号（例如，MySQL 5.7.10）。您可以通过执行 mysqladmin version 找出您正在运行的版本。可以在 MySQL 安装目录下的 bin 目录中找到 mysqladmin 程序。

  2. 出现问题的机器的制造商和型号。

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

  4. 有时内存容量（真实内存和虚拟内存）也很重要。如果有疑问，请包括这些值。

  5. 你 MySQL 安装中的 docs/INFO_BIN 文件的内容。此文件包含 MySQL 配置和编译方式相关的信息。

  6. 如果你使用的是 MySQL 软件的源发行版，请包括所用编译器的名称和版本号。如果你有二进制发行版，请包括发行版名称。

  7. 如果在编译过程中出现问题，请包括确切的错误消息以及在发生错误的文件中冒犯代码周围的几行上下文。

  8. 如果 mysqld 终止，您还应报告导致 mysqld 意外退出的语句。通常，可以通过在启用查询日志记录的情况下运行 mysqld 获取此信息，然后在 mysqld 退出后查看日志。请参阅 Section 7.9, “Debugging MySQL” 。

  9. 如果一个数据库表与问题相关，请在错误报告中包含 SHOW CREATE TABLE _db_name . tbl_name_ 语句的输出。这是获取数据库中任何表的定义的非常简单的方法。该信息能帮助我们创建与您遇到的情况相符的情形。

  10. 当问题发生时生效的 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;

  11. 对于与 SELECT 语句相关的性能相关问题或问题，您应始终包括 EXPLAIN SELECT &#8230;&#8203; 的输出，以及至少 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>_

  1. 如果在运行 mysqld 时发生故障或问题，请尝试提供重现异常现象的输入脚本。此脚本应包含所有必要的源文件。此脚本越能重现您的情况，越好。如果您能够形成可复制的测试案例，您应该上传此案例并将其附加到错误报告中。

如果您无法提供脚本，则您应该至少在您的报告中包含 mysqladmin variables extended-status processlist 的输出信息，以供了解您的系统执行方式。

  1. 如果您无法仅通过几行生成测试案例，或者如果测试表过大而无法包含在错误报告中（超过 10 行），则您应该使用 mysqldump 转储表格，并创建一个描述您问题的 README 文件。使用 tar 和 gzip ，或 zip ，创建文件的压缩存档。在为我们的错误报告数据库启动一个错误报告后，请点击错误报告中的“文件”选项卡，了解将存档上传到错误报告数据库的说明。

  2. 如果你认为 MySQL 服务器从某个语句产生了奇怪的结果，不仅要包括结果，还要包括你认为结果应该是什么以及解释说明你意见的依据。

  3. 当你提供问题的示例时，最好使用实际情况下存在的表名、变量名等，而不是想出新名称。问题可能与表名或变量名相关。这些情况可能很少见，但小心谨慎总比后悔好。毕竟，从实际情况中提供一个示例对你来说应该更容易，而且对我们来说也更好。如果你有不想在 Bug 报告中向其他人展示的数据，则可以使用“文件”选项卡，如前所述进行上传。如果信息真的属于最高机密，你甚至不想向我们展示，请使用其他名称提供一个示例，但请将其视为最后的选择。

  4. 如果您能够提供，请包含提供给相关程序的所有选项。例如，指出您启动 mysqld 服务器时使用的选项以及运行任何 MySQL 客户端程序时使用的选项。如 mysqld 和 mysql 这样的程序以及 configure 脚本中的选项通常都是解决问题的关键，并非常重要。将它们包含其中永远不会出错。如果您遇到的问题涉及使用 Perl 或 PHP 等语言编写的程序，请包含语言处理器的版本号以及该程序使用的任何模块的版本。例如，如果您有一个使用 DBI 和 DBD::mysql 模块的 Perl 脚本，则包含 Perl 的版本号、 DBI 和 DBD::mysql 。

  5. 如果您遇到的问题与权限系统有关，请包含 mysqladmin reload 的输出以及您在尝试连接时收到的所有错误消息。您在测试您的权限时，您应该执行 mysqladmin reload version 并且尝试使用造成您问题的那程序进行连接。

  6. 如果您有漏洞补丁，请一并提供。但不要想当然地认为补丁就是万岁，或者我们能用它，如果您没有提供一些必要的信息，比如显示补丁修复的漏洞的测试用例。我们可能发现您补丁的问题，或者根本不理解。如果是这样，我们就无法使用它。

如果我们无法验证补丁的确切目的，我们就不会使用它。测试用例在这里对我们有帮助。显示补丁处理所有可能出现的情况。如果我们发现补丁不起作用的界线情况（即便罕见），它可能就毫无用处。

  1. 关于漏洞是什么、为何出现或依赖于什么的猜测通常是错误的。即使是 MySQL 团队在不首先使用调试器确定漏洞的真正原因的情况下也不能猜到这些事情。

  2. 在您的漏洞报告中表明您已查阅参考手册和邮件存档，以便他人知道您已尝试自己解决问题。

  3. 如果您看到您的数据已毁损，或在访问一个特定的表格时收到错误信息，请首先使用 CHECK TABLE 检查您的表格。如果此语句报告任何错误：

InnoDB 崩溃恢复机制能在服务器被杀死并重启后处理清理，所以在典型的操作中没有必要“修复”表格。如果您使用 InnoDB 表格时遇到错误信息，请重启服务器并观察问题是否仍然出现，或者错误是否仅影响到内存中的已缓存数据。如果磁盘数据已毁损，请考虑使用启用了 innodb_force_recovery 选项重启服务器，以便您可以转储受影响的表格。

对于非事务性表格，尝试使用 REPAIR TABLE 或 myisamchk 来修复它们。请参阅 Chapter 7, MySQL Server Administration 。

如果您正在运行 Windows，请使用 SHOW VARIABLES LIKE 'lower_case_table_names' 语句验证 lower_case_table_names 的值。此变量影响服务器如何处理数据库和表格名称的字母大小写。对于给定值，其作用应如 Section 11.2.3, “Identifier Case Sensitivity” 中所述。

  1. InnoDB 崩溃恢复机制能在服务器被杀死并重启后处理清理，所以在典型的操作中没有必要“修复”表格。如果您使用 InnoDB 表格时遇到错误信息，请重启服务器并观察问题是否仍然出现，或者错误是否仅影响到内存中的已缓存数据。如果磁盘数据已毁损，请考虑使用启用了 innodb_force_recovery 选项重启服务器，以便您可以转储受影响的表格。

  2. 对于非事务性表格，尝试使用 REPAIR TABLE 或 myisamchk 来修复它们。请参阅 Chapter 7, MySQL Server Administration 。

  3. 如果您经常看到表格数据毁损，您应该尝试找出在何时何地发生了这种情况。在这种情况下，MySQL 数据目录中的错误日志会包含一些关于发生的事情的信息。（此文件名称中带有 .err 后缀。）请参阅 Section 7.4.2, “The Error Log” 。请在您的错误报告中包含此文件中的所有相关信息。通常 mysqld 会 never 毁损表格，如果它在更新过程中未被杀死。如果您能找出杀死 mysqld 的原因，我们就能更容易地为您提供修复这个问题的解决方案。请参阅 Section B.3.1, “How to Determine What Is Causing a Problem” 。

  4. 如果可能，下载并安装 MySQL Server 的最新版本，并检查它是否能解决您的问题。所有版本的 MySQL 软件都经过全面测试，应能正常工作。我们相信尽可能地向后兼容，您应该能够毫不费力地切换 MySQL 版本。参见 Section 2.1.2, “Which MySQL Version and Distribution to Install”。