首先，搜索 MySQL 在线手册在https://dev.mysql.com/doc/。我们尽量保持手册的最新性，通过频繁地更新解决新发现的问题。在此外，手册附件的发行说明可能非常有用，因为它很可能包含了解决问题的方案。发行说明可在给定的位置找到。

如果您对 SQL 语句出现解析错误，请检查语句的语法。如果找不到语法错误，那么您的当前 MySQL 服务器版本不支持该语法。如果您使用的是最新版本且手册不涵盖该语法，MySQL 服务器就不支持该语句。

如果手册涵盖了该语法，但是您使用的是较旧的 MySQL 服务器版本，那么您可以查看 MySQL 变更历史，以了解该语法何时实现。在这种情况下，您有升级到最新版本的 MySQL 服务器的选择。

对于一些常见的问题，见第 B.3 节，“问题和常见错误”。

搜索bugs数据库在http://bugs.mysql.com/，以查看该bug是否已经报告并且修复过了。

您也可以使用http://www.mysql.com/search/来搜索 MySQL 网站上的所有页面（包括手册）。

您正在使用的 MySQL 发行版号（例如，MySQL 5.7.10）。您可以通过执行mysqladmin version来确定当前运行的版本号。mysqladmin程序位于您的 MySQL 安装目录下的bin目录中。

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

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

有时内存的大小（实际和虚拟）是相关的。如果怀疑，包括这些值。

MySQL 安装包中的docs/INFO_BIN文件的内容。这文件包含了 MySQL 的配置和编译信息。

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

如果出现编译错误，包括精确的错误消息，并且在错误发生的文件中包括几行上下文。

如果mysqld崩溃，您也应该报告导致mysqld意外退出的语句。您通常可以通过启用查询日志，运行mysqld，然后在日志中查看退出信息。见第7.9节，“调试 MySQL”。

如果数据库表与问题相关，请在bug报告中包含来自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 输出。提供关于您的情况的更多信息，someone就更可能帮助您。

以下是一个非常好的错误报告示例。语句使用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 的输出，以提供系统性能信息。

如果您不能使用少于几行数据创建测试用例，或者测试表太大无法包含在bug报告中（超过10行），那么应该使用mysqldump将表dump出来，并创建一个README文件来描述您的问题。使用tar和gzip或zip将文件压缩成归档。您在http://bugs.mysql.com/创建bug报告后，点击Files标签了解如何上传归档到bug数据库。

如果您认为MySQL服务器从语句中产生了奇怪的结果，请包括不仅结果，还有您的看法和解释，描述您的看法基础。

当您提供问题示例时，使用实际情况中的表名、变量名等更好，而不是随便创建新的名称。这个问题可能与表名或变量名相关，这种情况很少，但总之安全第一。如果您有不想让他人看到的数据，可以使用Files标签上传它，如前所述。如果信息真的非常机密，不想我们看到，使用其他名称，但是请认为这是最后选择。

包括所有相关程序的选项，如果可能。例如，指出你启动mysqld 服务器时使用的选项，以及运行任何 MySQL 客户端程序时使用的选项。像mysqld 和 mysql，以及configure 脚本的选项，通常是解决问题的关键。总之，包括它们从不坏。如果你的问题涉及到语言如 Perl 或 PHP 的程序，请包括语言处理器的版本号，以及该程序使用的模块的版本号。例如，如果你有一个使用 DBI 和 DBD::mysql 模块的 Perl 脚本，包括 Perl、DBI 和 DBD::mysql 的版本号。

如果你的问题与权限系统相关，请包括mysqladmin reload 的输出，以及你尝试连接时获取的所有错误信息。测试你的权限时，你应该执行mysqladmin reload version，然后使用给你麻烦的程序尝试连接。

如果您有一个bug的补丁，请包括它。但是，不要假设补丁就是我们需要的，也不要假设我们可以使用它，如果您不提供一些必要的信息，例如显示补丁修复的bug的测试用例。我们可能会发现补丁的问题，也可能无法理解。如果是这样，我们就不能使用它。

如果我们不能验证补丁的确切目的是什么，我们就不会使用它。测试用例可以帮助我们这里。显示补丁处理所有可能出现的情况。如果我们找到一个边界情况（即使很少见的一种），补丁可能无效。

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

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

如果您的数据出现损坏或访问某个表时出现错误，首先使用CHECK TABLE语句检查表。如果该语句报告任何错误：

如果您正在运行 Windows，请使用 SHOW VARIABLES LIKE 'lower_case_table_names' 语句验证lower_case_table_names 的值。这個变量影响服务器对数据库和表名的字母大小写。其效果对于给定的值应如同在第11.2.3节，“标识符字母大小写”中描述。

如果您经常遇到损坏的表，您应该尝试找到是什么时候和为什么发生这种情况。在这种情况下，MySQL 数据目录中的错误日志可能包含一些关于发生的事情的信息（该文件名以.err后缀结尾）。见第7.4.2节，“错误日志”。请在bug报告中包含来自该文件的任何相关信息。通常mysqld不应该如果没有中断更新就损坏一个表。如果您可以找到mysqld死机的原因，那么我们更容易为您提供解决问题的方法。见第B.3.1节，“确定是什么造成问题”。

如果可能，请下载并安装最新版本的 MySQL 服务器，并检查是否解决了您的问题。MySQL 软件的所有版本都经过了充分测试，应该无问题。如果您可以轻松地切换 MySQL 版本，我们也尽量保持向后兼容性。见第2.1.2节，“安装哪个 MySQL 版本和分布式”。