欢迎大家关注专栏或者关注收藏我
1.Mysql精通之路专栏:
http://t.csdnimg.cn/4Rqp7
2.大家可以从这篇博客开始读，他是所有博客的根节点：
【MySQL精通之路】详读MySQL8.0官方文档-CSDN博客
目录
1.提交报告前
在发布有关问题的错误报告之前，请尝试验证这是一个错误，并且尚未报告：
1.首先在上搜索MySQL在线手册https://dev.mysql.com/doc/.
我们经常更新手册，以解决新发现的问题，从而使手册保持最新。此外，手册附带的发行说明可能特别有用，因为更新的版本很可能包含您的问题的解决方案。发布说明可在刚刚为手册提供的位置找到。
2.如果您收到SQL语句的解析错误，请仔细检查您的语法。
如果您找不到它的错误，那么很可能您当前版本的MySQL Server不支持您正在使用的语法。如果您使用的是当前版本，并且手册没有涵盖您使用的语法，那么MySQL Server不支持您的声明。
如果手册涵盖了您正在使用的语法，但您有一个旧版本的MySQL Server，您应该查看MySQL的更改历史记录，看看该语法是何时实现的。在这种情况下，您可以选择升级到更新版本的MySQL Server。
3.有关一些常见问题的解决方案，请参阅第B.3节“问题和常见错误”。
4.Bug数据库http://bugs.mysql.com/以查看是否已报告并修复错误。
5.http://www.mysql.com/search/搜索MySQL网站上的所有网页（包括手册）。
1.1 报告错误指南
如果您在手册、错误数据库或邮件列表档案中找不到答案，请咨询您当地的MySQL专家。如果您仍然找不到问题的答案，请使用以下指南报告错误。
http://bugs.mysql.com/，这是我们bug数据库的地址。这个数据库是公共的，任何人都可以浏览和搜索。如果您登录到系统，则可以输入新的报告。
错误数据库中发布的错误位于http://bugs.mysql.com/在发行说明中注明了针对给定发行版更正的。
1.2 安全漏洞
如果您在MySQL Server中发现安全漏洞，请立即发送电子邮件至<secalert_us@oracle.com>.
例外情况：
支持客户应向Oracle支持部门报告所有问题，包括安全漏洞，网址为http://support.oracle.com/.
1.3 社区
要与其他用户讨论问题，您可以使用MySQL社区Slack。
2.写报告
写一份好的bug报告需要耐心，但第一次做对就可以为我们和你自己节省时间。一个好的bug报告，包含bug的完整测试用例，使我们很可能在下一个版本中修复bug。本节帮助您正确撰写报告，这样您就不会浪费时间做对我们帮助不大或根本没有帮助的事情。请仔细阅读本节，并确保此处描述的所有信息都包含在您的报告中。
最好，在发布之前，您应该使用MySQL Server的最新生产或开发版本来测试这个问题。任何人都应该能够通过在测试用例中使用 mysql test < script_file ，或者通过运行错误报告中包含的shell或Perl脚本来重复该错误。我们能够重复的任何错误都很有可能在下一个MySQL版本中得到修复。
当错误报告中包含对问题的良好描述时，这是最有帮助的。也就是说，举一个很好的例子，说明你所做的导致问题的一切，并准确详细地描述问题本身。最好的报告包括一个完整的示例，说明如何重现错误或问题。请参阅第7.9节“调试MySQL”。
请记住，我们可以对包含过多信息的报告作出回应，但不能对包含过少信息的报告做出回应。人们经常忽略事实，因为他们认为自己知道问题的原因，并认为一些细节无关紧要。一个很好的原则是，如果你对陈述有疑问，就陈述出来。如果我们必须要求你提供最初报告中缺失的信息，那么在报告中多写几行比等待更长时间的答案更快、更不麻烦。
2.1 常见写报告错误
错误报告中最常见的错误是：
（a）没有包括您使用的MySQL发行版的版本号
（b）没有完全描述安装MySQL服务器的平台（包括平台类型和版本号）。
这些都是高度相关的信息，在百分之九十九的情况下，没有它们，错误报告就毫无用处。
我们经常会遇到这样的问题：“为什么这对我不起作用？”然后我们发现请求的功能没有在那个MySQL版本中实现，或者报告中描述的错误已经在较新的MySQL版本中修复。错误通常取决于平台。
在这种情况下，我们几乎不可能在不知道操作系统和平台版本号的情况下修复任何东西。
2.2 其他情况
如果您从源代码编译MySQL，请记住，如果与问题有关，还应提供有关编译器的信息。人们经常在编译器中发现错误，并认为问题与MySQL有关。大多数编译器一直在开发中，并且一个版本接一个版本地变得更好。为了确定您的问题是否取决于您的编译器，我们需要知道您使用了什么编译器。请注意，每一个编译问题都应该被视为一个bug，并相应地进行报告。
如果程序生成错误消息，那么在报告中包含该消息是非常重要的。如果我们试图从档案中搜索某些内容，最好报告的错误消息与程序生成的错误消息完全匹配。（甚至要注意信纸。）最好将整个错误信息复制并粘贴到报告中。你永远不应该试图从记忆中重现信息。
如果连接器/ODBC（MyODBC）有问题，请尝试生成跟踪文件并将其与报告一起发送。请参阅如何报告连接器/ODBC问题或错误。
如果您的报告包含使用mysql命令行工具运行的测试用例的长查询输出行，则可以使用--vertical选项或\G语句终止符使输出更具可读性。本节后面的EXPLAIN SELECT示例演示了\G。
3.包含的内容
请在您的报告中包括以下信息：
您正在使用的MySQL发行版的版本号（例如，MySQL 5.7.10）。
您可以通过执行mysqladmin版本来找出您正在运行的版本。
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变量扩展状态处理列表的输出，以提供有关系统运行情况的一些信息。
如果您不能生成只有几行的测试用例，或者测试表太大而无法包含在错误报告中（超过10行）
则应该使用mysqldump转储表，并创建一个自述文件来描述您的问题。使用tar和gzip或zip创建文件的压缩存档。在您为我们的错误数据库启动错误报告后http://bugs.mysql.com/，单击错误报告中的“文件”选项卡以获取有关将存档上载到错误数据库的说明。
如果你认为MySQL服务器从一个语句中产生了一个奇怪的结果
那么不仅要包括结果，还要包括你对结果应该是什么的看法，以及描述你的看法的基础的解释。
当您提供问题的示例时
最好使用实际情况中存在的表名、变量名等，而不是使用新名称。问题可能与表或变量的名称有关。这种情况可能很少见，但安全总比抱歉好。毕竟，您应该更容易提供一个使用您实际情况的示例，而且这对我们来说绝对更好。如果您有不想在错误报告中被其他人看到的数据，您可以使用前面描述的“文件”选项卡上传。如果这些信息真的是绝密信息，而您甚至不想向我们展示，请继续使用其他名称提供一个示例，但请将此视为最后的选择。
如果可能的话，包括提供给相关项目的所有选项。例如，指示启动mysqld服务器时使用的选项，以及用于运行任何MySQL客户端程序的选项。mysqld和mysql等程序以及配置脚本的选项通常是解决问题的关键，并且非常相关。把它们包括在内从来都不是一个坏主意。如果您的问题涉及用Perl或PHP等语言编写的程序，请包括语言处理器的版本号，以及该程序使用的任何模块的版本。例如，如果您有一个使用DBI和DBD:：mysql模块的Perl脚本，请包括Perl、DBI和DBD:：mysql的版本号。
如果您的问题与特权系统有关
请包括mysqladmin重载的输出，以及您在尝试连接时收到的所有错误消息。当您测试您的权限时，您应该执行mysqladmin reload版本，并尝试连接给您带来麻烦的程序。
如果你有一个bug的补丁
一定要包括它。但是，如果你没有提供一些必要的信息，比如显示你的补丁修复的bug的测试用例，不要认为这个补丁就是我们所需要的，或者我们可以使用它。我们可能会发现您的补丁有问题，或者我们可能根本不了解它。如果是这样，我们就不能使用它。
如果我们无法验证补丁的确切用途，我们将不会使用它。
测试案例在这里帮助我们。显示修补程序可处理所有可能发生的情况。如果我们发现补丁不起作用的临界情况（即使是罕见的情况），它可能毫无用处。
对错误是什么、为什么会发生或依赖于什么的猜测通常是错误的。如果不首先使用调试器来确定错误的真正原因，即使是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 Server，并检查它是否解决了您的问题。MySQL软件的所有版本都经过了彻底的测试，应该可以正常工作。我们相信要使所有东西尽可能向后兼容，并且您应该能够毫无困难地切换MySQL版本。请参阅第2.1.2节，“安装哪个MySQL版本和发行版”。