mysql5.0api_MySQL 5.1中文参考手册

张贴缺陷报告或问题之前，请：

·首先搜索MySQL在线手册，http://dev.mysql.com/doc/。我们经常更新该手册，以使该手册保持最新，其中包含相应的解决方案和新发现的问题。变更史(http://dev.mysql.com/doc/mysql/en/News.html)可能更有用，原因在于，在较新的版本中可能包含对你所提出问题的解决方案。

·搜索缺陷数据库，http://bugs.mysql.com/，查找该缺陷是否已通报或更正。

·你也可以使用http://www.mysql.com/search/来搜索MySQL AB网站上的所有网页(包含手册)。

如果无法在手册或档案中找到答案，请与本地MySQL专家协商。如果仍无法获得解答，在与我们联系之前，请按照介绍发送电子邮件至MySQL邮件列表，具体内容见下一节。

1.7.1.3. 如何通报缺陷和问题

通报缺陷的正常地址是http://bugs.mysql.com/，它也是我方缺陷数据库的地址。这是1个公共数据库，任何人都能浏览它并进行相应的搜索。如果登录到系统，可输入新的报告。

编写良好的缺陷报告需要耐心，但在第1时间正确地完成它不仅能节省我们的时间，也能节省你自己的时间。良好的缺陷报告应包含对缺陷的完整测试情况，以便我们能够在下个版本中更正该缺陷。本节介绍的内容用于帮助你正确地编写报告，从避免将你的时间浪费在对我们帮助不大或没有帮助的事上，

我们鼓励任何人使用mysqlbug脚本来生成缺陷报告(或通报问题)。Mysqlbug可在脚本目录下找到(源码分发版)，也能在MySQL安装目录的bin子目录下找到(二进制分发版)。如果不能使用mysqlbug(例如，如果你正在Windows平台上运行)，应包括本节所述的所有必要信息(更重要的是，应介绍操作系统和MySQL版本)，这点十分重要。

通过自动确定下述信息，mysqlbug脚本能够帮助你生成报告，但是，如果遗漏了某些重要事项，请将其包含在消息中。请认真阅读本节，并确保在你的报告中包含了本节所述的所有信息。

在张贴问题前，最好使用MySQL服务器的最新生产版或开发版对问题进行测试。通过在所含的测试范例上使用“mysql test < script_file”，或运行缺陷报告中所含的Shell或Perl脚本，任何人均应能重复该缺陷。

对于在缺陷数据库(http://bugs.mysql.com/)中张贴的所有缺陷，均会被纳入或记录在下一个MySQL版本中。如果只需要少量更改就能更正问题，我们或许会给出更正该问题的补丁。

如果发现MySQL中存在敏感的安全缺陷，请发送电子邮件至security@mysql.com。

如果有1份可重复的缺陷报告，请将其提交到缺陷数据库，http://bugs.mysql.com/。注意，即使在该情况下，也应首先运行mysqlbug脚本以找出与你的系统有关的信息，这是一个不错的习惯。对于任何我们能再现的缺陷，在下一个MySQL版本中修正它的机会很大。

要想通报其他问题，请使用MySQL邮件列表。

请注意，我们可能会对包含过多信息的消息做出响应，但不太会对包含过少信息的消息做出回应。人们常会省略掉一些事实，因为他们认为自己知道了故障的原因，并想当然地认为这类细节无关紧要。良好的原则是： 如果你对陈述某事犹豫不定，请陈述之。如果我们要求你提供初始报告中缺少的信息，在报告中编写多行信息源比等候回复要快，麻烦也更小。

在缺陷报告中，最常犯的错误包括：(a)未包含所使用MySQL的版本号，以及(b)未完全描述安装了MySQL服务器的平台(包括平台类型，以及版本号)。这是高度相关的信息，如果没有它，99％的缺陷报告无用。我们遇到这类问题，“为何它对我没用”？ 随后，我们发现在该MySQL版本中，所请求的特性尚未实施，或在较新的MySQL版本中已更正了报告中描述的缺陷。有些时候，错误与平台相关，在这类情况下，如果不知道操作系统和平台的版本号，我们几乎不可能更正任何问题。

如果你是从源码编译MySQL的，如果与问题有关，还应提供有关编译器的信息。问题经常出在编译器，但人们却认为问题与MySQL有关。大多数编译均处于不断的开发过程中，并会变得越来越好。为了确定问题是否与你的编译器有关，我们需要知道你所使用的编译器。注意，所有的编译问题均应被当作缺陷并予以通报。

在你的报告中包含良好的问题描述时，报告最有帮助。也就是说，应给出示例，指明导致问题的所有事项，并准确描述问题本身。最好的报告应包含完整的示例，这类示例应阐明再现缺陷或问题的方式。请参见E.1.6节，“如果出现表崩溃，请生成测试案例”。

如果程序产生了错误消息，也应将其包含在你的报告中，这点很重要。如果我们打算使用程序搜索档案，最好是通报的错误消息与程序生成的错误消息准确匹配。(即使是字母的大小写也应考虑在内)。永远不要尝试从记忆中再现错误消息，而是应将整个消息拷贝并粘贴到报告中。

如果遇到与Connector/ODBC (MyODBC)有关的问题，请生成1份跟踪文件，并与报告一起发送给我们。请参见26.1.1.9节，“如何通报MyODBC问题或缺陷”。

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

·你所使用的MySQL分发版的版本号(例如MySQL 4.0.12)。通过执行mysqladmin version，即可了解正在运行版本。Mysqladmin程序位于MySQL安装目录的bin子目录下。

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

·操作系统的名称和版本。如果你使用的是Windows操作系统，通常能通过双击“我的电脑”图标并点击“帮助/关于Windows”菜单来了解操作系统的名称和版本。对于大多数Unix操作系统，可通过执行命令uname –a获取这类信息。

·某些时候，内存容量(实际内存和虚拟内存)也有关系。如果怀疑它，也应包含这类数值。

·如果你正在使用的是MySQL软件的源码分发版，还须提供所使用编译器的名称和版本。如果使用的是二进制分发版，需要提供其名称。

·如果在编译过程中出现问题，应给出准确的错误消息，出错文件中的不良代码，以及该代码附近的数行内容。

·如果mysqld停止运行，还应通报导致mysqld崩溃的查询。通常，能够通过运行启用了查询日志功能的mysqld找出它，然后在mysqld崩溃后查找日志。请参见E.1.5节，“使用日志文件找出mysqld中的错误原因”。

·如果数据库表与问题有关，还应包含mysqldump --no-datadb_nametbl_name的输出。这是一种了解数据库中表相关信息的简单易行而且功能强大的方式。该信息能帮助我们建立与你所遇到的情况相匹配的场景。

·对于与SELECT语句的速度有关的缺陷或问题，总应包含“EXPLAIN SELECT ...”的输出，以及SELECT语句生成的行数(至少)。对于每个涉及的表，应包含SHOW CREATE TABLE tbl_name的输出。你所提供的关于具体情况的信息越多，得到帮助的可能性就越大。

下面给出了一个良好缺陷报告的示例。应使用mysqlbug脚本张贴它。本例采用了mysql命令行工具。对于输出内容可能会超过80列显示器可用宽度的语句，应使用“\G”语句终结符。mysql> SHOW VARIABLES;mysql> SHOW COLUMNS FROM ...\Gmysql> EXPLAIN SELECT ...\Gmysql> FLUSH STATUS;mysql> SELECT ...;mysql> SHOW STATUS;

·如果在运行mysqld时出现错误或问题，应提供导致异常的输入脚本。该脚本应包含任何所需的源文件。越能再现具体情况的脚本越好。如果能够创建可再现的测试范例，请将其张贴到http://bugs.mysql.com/，它将得到优先对待。

如果你不能提供脚本，至少应在你的邮件中包含mysqladmin variables extended-status processlist的输出，以提供关于系统执行情况的某些信息。

·如果不能生成包含数行内容的测试范例，或者如果测试表过大以至于无法发送到邮件列表(超过10行)，应使用mysqldump转储表，并创建描述问题的README文件。

·如果你认为MySQL服务器生成了奇怪的查询结果，不仅应包含结果，还应给出你对该结果的看法，以及支持观点的基础。

·提供问题的示例时，最好使用实际情况下已有的变量名、表名等，而不是新名称。问题可能与变量名或表名有关。或许这类情况很罕见，但安全总比道歉强。归根结底，对你来说，提供关于实际情况的示例要简单些，当然对我们也更好。如果你的数据不打算展示给其他人，请使用FTP将其传输到ftp://ftp.mysql.com/pub/mysql/upload/。如果信息是高度保密的，而且你甚至不打算向我们展示，请使用其他名称给出示例，但请注意，这应是最后的选择。

·如果可能，应包含相关程序的所有选项。例如，应指明启动mysqld服务器时使用的选项，以及用来运行MySQL客户端程序的选项。对于程序(如mysqld和mysql)选项以及configure脚本的选项，通常是解答问题的关键，关系十分密切。包含它们总不是坏主意。如果使用了任何模块，如Perl或PHP等，还应给出它们的版本。

·如果你的问题与权限系统有关，请给出mysqlaccess的输出，mysqladmin reload的输出，以及进行连接时获得的所有错误消息。测试权限时，首先应运行mysqlaccess。接下来，执行mysqladmin reload version，并与导致问题的程序相连。mysqlaccess可在MySQL安装目录的bin子目录下找到。

·如果你有关于某一缺陷的补丁，也请将它包含在内。但不要认为该补丁是我们所需的全部，如果未提供补丁所更正缺陷的必要信息(如测试范例)，不要假定我们会使用它。我们可能会通过补丁发现问题，或者不能理解该补丁，如果是这样，我们不会使用该补丁。

如果我们不能准确核实补丁的目的，将不会使用它。测试范例会对我们有所帮助。请指明该补丁能处理所有的问题。如果我们发现补丁不能工作的临界情况(即使很罕见)，它可能是无用的。

·关于缺陷是什么、出现原因、以及缺陷导因的猜测通常是错的。即使是MySQL团队，在未使用调试器判定缺陷真实原因的情况下，也不能妄加猜测。

·请在你的缺陷报告中指明，你已参阅了参考手册并寄出了档案，以便让其他人知道你已作了自行解决问题的尝试。

·如果遇到解析错误，请仔细检查语法。如果不能找出错误出现在那里，很可能是因为你使用的MySQL服务器版本不支持你使用的语法。如果你使用的是http://dev.mysql.com/doc/上提供的当前版本和手册，不要包含你所使用的语法，MySQL服务器不支持你的查询。在这种情况下，唯一的选择是自行实施语法，或发送电子邮件至

如果手册中涵盖了你所使用的语法，但你使用的是旧版本MySQL服务器，请检查MySQL变更史，以查看语法的实施时间。在这种情况下，可以选择升级到较新的MySQL服务器版本。请参见附录D：MySQL变更史。

·如果问题在于数据崩溃，或访问特殊表时出错，首先应使用CHECK TABLE和REPAIR TABLE或myisamchk进行检查并尝试修复。请参见第5章：数据库管理。

如果你使用的操作系统是Windows，请使用SHOW VARIABLES LIKE 'lower_case_table_names'命令核实“lower_case_table_names”的值。

·如果经常获得崩溃的表，请尝试找出发生的时间和原因。在这种情况下，MySQL数据目录下的错误日志可能会包含关于它的一些信息。(这是名称中包含.err后缀的文件)。请参见5.11.1节，“错误日志”。在你的缺陷报告中，请包含该文件提供的相关信息。如果在更新期间，未杀死更新进程，正常情况下，mysqld不会造成表损坏。如果你能够找到mysqld停止的原因，我们会更容易地为你提供更正它的补丁。请参见A.1节，“如何确定导致问题的原因”。

如果你是享受支持服务的客户，请将缺陷报告交叉张贴在mysql-support@mysql.com，以获得更高的优先级，并将其张贴到恰当的邮件列表，以查看是否有人遇到了类似问题(或解决了问题)。

关于某些常见问题的解决方案，请参见附录A：问题和常见错误。

将答案单独发送给你而不是发送到邮件列表时，良好的礼节是，对回答进行归纳总结并将结果发送到邮件列表，以便其他人也能从你所收到、并解决了问题的回应中受益。