要想订购本节所介绍的邮件列表或取消订购，请访问http://lists.mysql.com/。对于大多数邮件列表，可选择能够获取单独消息的正规列表版本，或选择按天发布的包含大量消息的文摘版本。

不要将订购信息或取消订购的信息发送到邮件列表，原因在于，这类消息将自动分发给数千位其他用户。

在你的所在地，可能有很多MySQL邮件列表的订户。如果是这样，该地点可能会有本地邮件列表，这样，从lists.mysql.com发出的消息将被传播到本地列表。在这类情形下，请与你的系统管理员联系，添加或删除本地MySQL列表。

如果希望将邮件列表的信息传送到邮件程序的邮箱中，请根据消息标题设置过滤器。可以使用列表ID： 或投递至： 识别列表消息的标题。

MySQL列表包含：

·         通告

该列表用于通告新的MySQL版本和相关程序。这是1种低容量列表，所有的MySQL用户均应订购它。

·         mysql

这是关于一般MySQL讨论的主要列表。请注意，对于某些主题来说，在更专门的列表中会得到更好地讨论。如果将问题张贴到了错误的列表，可能不会得到回答。

·         缺陷

该列表面向那些希望随时了解自上次MySQL版本发布以来已通报事宜的人员，或希望积极参与缺陷寻找和更正进程的人员。请参见1.7.1.3节，“如何通报缺陷和问题”。

·         内部构件

该列表面向那些与MySQL代码打交道的人员。它也是讨论MySQL开发并张贴补丁的论坛。

·         mysqldoc

该列表面向那些与MySQL文档打交道的人员： MySQL AB公司的人员，译者，以及其他社区成员。

·         基准

该列表面向任何对性能事宜感兴趣的人员。讨论主要集中在数据库性能方面（不限于MySQL），也包括更广的类别，如内核性能、文件系统、磁盘系统等。

·         packagers（包装程序）

该列表主要讨论包装和分发MySQL方面的问题。这是供分发版维护人员交流MySQL打包事宜的论坛，为的是确保在所有支持的平台和操作系统上，MySQL的外观和感觉尽可能类似。

·         java

该列表主要讨论MySQL服务器和Java方面的问题。它主要讨论JDBC驱动程序，包括MySQL Connector/J。

·         win32

该列表涵盖了在Microsoft操作系统环境下（如Windows 9x, Me, NT, 2000, XP和2003）与MySQL软件有关的所有主题，

·         myodbc

该列表涵盖了与使用ODBC连接到MySQL服务器有关的所有主题。

·         gui-tools

该列表涵盖了与MySQL GUI工具有关的所有主题，包括MySQL管理员以及MySQL控制中心图形客户端。

·         cluster

该列表主要讨论MySQL簇。

·         dotnet

该列表主要讨论MySQL服务器和.NET平台方面的问题。它与MySQL Connector/Net提供人的关系最密切。

·         plusplus

该列表涵盖了使用C++ API进行MySQL编程的所有主题。

·         perl

该列表涵盖了与Perl对MySQL支持、以及DBD::mysql有关的所有主题。

如果无法从MySQL邮件列表或论坛获得问题解答，一种选择是购买MySQL AB的支持服务。这样，你就能与MySQL开发人员直接联系。

下面介绍了一些英语以外其他语言的MySQL邮件列表。这些邮件列表不是由MySQL AB运营的。

·         <[email protected]>

法语邮件列表。

·         <[email protected]>

朝鲜语邮件列表。发送电子邮件订购mysql [email protected]。

·         <[email protected]>

德语邮件列表。发送电子邮件订购mysql-de [email protected]。在http://www.4t2.com/mysql/站点上，可找到关于该邮件列表的更多信息。

·         <[email protected]>

葡萄牙语邮件列表。发送电子邮件订购mysql-br [email protected]。

·         <[email protected]>

西班牙语邮件列表。发送电子邮件订购mysql [email protected]。

通报缺陷的正常地址是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中存在敏感的安全缺陷，请发送电子邮件至[email protected]。

如果有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问题或缺陷”。

请记住，很多阅读你报告的人员会使用80列的显示器。使用mysql命令行工具生成报告或示例时，如果输出内容可能会超过这类显示器的可用宽度，应使用“--vertical”选项（或“\G”语句终结符），例如EXPLAIN SELECT语句，请参见本节后面给出的示例。

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

·         你所使用的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-data db_name tbl_name的输出。这是一种了解数据库中表相关信息的简单易行而且功能强大的方式。该信息能帮助我们建立与你所遇到的情况相匹配的场景。

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

下面给出了一个良好缺陷报告的示例。应使用mysqlbug脚本张贴它。本例采用了mysql命令行工具。对于输出内容可能会超过80列显示器可用宽度的语句，应使用“\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时出现错误或问题，应提供导致异常的输入脚本。该脚本应包含任何所需的源文件。越能再现具体情况的脚本越好。如果能够创建可再现的测试范例，请将其张贴到http://bugs.mysql.com/，它将得到优先对待。

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

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

使用tar和gzip或zip创建文件的压缩包档案，并使用FTP将档案传输到ftp://ftp.mysql.com/pub/mysql/upload/。然后将问题提交到我们的缺陷数据库中，http://bugs.mysql.com/。

·         如果你认为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服务器不支持你的查询。在这种情况下，唯一的选择是自行实施语法，或发送电子邮件至<[email protected]>，并寻求实施方案。

如果手册中涵盖了你所使用的语法，但你使用的是旧版本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服务器，并检查你的问题是否得到解决。所有版本的MySQL软件均经过彻底测试，并应能无故障运行。我们致力于尽可能地向后兼容，你也应能够毫不困难地在不同的MySQL版本间进行切换。请参见2.1.2节，“选择要安装的MySQL分发版”。

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

关于通报MyODBC中存在缺陷的更多信息，请参见26.1.1.9节，“如何通报MyODBC问题或缺陷”。

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

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

MySQL 4.1支持子查询和导出表。“子查询”指的是嵌套在另一语句中的SELECT语句。“导出表”（未命名视图）是另一语句的FROM子句中的子查询。请参见13.2.8节，“Subquery语法”。

从MySQL 4.1版起，可以使用联合或其他方法重写大多数子查询。关于如何完成该任务的更多信息，请参见13.2.8.11节，“对于较早的MySQL版本，采用联合方法重写子查询”。

MySQL服务器不支持Sybase SQL扩展： SELECT ... INTO TABLE ....。但MySQL服务器支持标准的SQL语法INSERT INTO ... SELECT ...，它基本上相同。请参见13.2.4.1节，“INSERT ... SELECT语法”。

INSERT INTO tbl_temp2 (fld_id)

    SELECT tbl_temp1.fld_order_id

    FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;

作为备选方式，可以使用SELECT INTO OUTFILE ...或CREATE TABLE ... SELECT。

从5.0版开始，MySQL支持SELECT ... INTO，以及用户变量。在使用光标和局部变量的存储程序中也可以使用相同的语法。请参见20.2.9.3节，“SELECT ... INTO语句”。

MySQL服务器（3.23至该系列的最高版本，所有4.0版本，以及更高版本）支持采用InnoDB和BDB事务存储引擎的事务。InnoDB提供了全面的ACID兼容性。请参见第15章：存储引擎和表类型。

MySQL服务器中的其他非事务性存储引擎（如MyISAM）遵从不同的数据完整性范例，称之为“原子操作”。按照事务术语，MyISAM表总能高效地工作在AUTOCOMMIT=1模式下。原子操作通常能提供可比较的完整性以及更好的性能。

由于MySQL服务器支持两种范例，因而你能决定是否利用原子操作的速度更好地服务于你的应用程序，或使用事务特性。该选择可按表进行。

正如所阐述的那样，事务性和非事务性表类型之间的权衡主要取决于性能。事务性表对内存和磁盘空间的要求更高，CPU开销也更大。另一方面，多种事务性表类型，如InnoDB，也能提供很多显著特性。MySQL服务器的模块化设计允许同时使用不同的存储引擎，以满足不同的要求，并在所有情形下，提供最佳性能。

但是，即便使用非事务性MyISAM表，你将如何使用MySQL服务器的特性来保持严格的完整性呢？这些特性与事务性表类型相比又如何呢？

1.    如果应用程序采用了特定的编写方式，依赖于在关键情况下能够调用ROLLBACK而不是COMMIT，那么事务性类型更方便。使用事务，还能确保未完成的更新或崩溃的活动不被提交到数据库，能为服务器提供自动回滚的机会，并保存你的数据库。

如果使用非事务性表，MySQL服务器几乎在所有情况下均允许你解决潜在的问题，方式是在更新前进行简单检查，并运行检查数据库一致性的简单脚本，如果出现不一致性，该脚本能自动修复它或给出告警。注意，仅使用MySQL日志或增加额外日志，通常能完美地更正表，同时不会造成数据完整性损失。

2.    在很多情况下，能够对关键的事务更新进行重写，使之成为“原子”类型。一般而言，所有由事务解决的完整性问题均能用LOCK TABLES或原子更新解决，从而确保了服务器不会自动中断，后者是事务性数据库系统的常见问题。

3.    为了安全使用MySQL服务器，无论是否使用事务性表，仅需启用备份和二进制日志功能。这样，你就能解决使用其他事务性数据库系统时遇到的任何问题。无论使用的数据库系统是什么，启用备份总是个好主意。

事务范型有自己的优点和不足之处。很多用户和应用程序开发人员喜欢这类简单性，在出现问题时或必要时，通过代码解决问题。但是，即使你是原子操作范型的新手，或更熟悉事务，也请考虑非事务性表的速度益处，与经过优化调整的最快的事务性表相比，它的速度快3～5倍。

在完整性具有最高重要性的情况下，即使是对非事务性表，MySQL也能提供事务级别的可靠性和安全性。如果使用LOCK TABLES锁定了表，所有更新均将被暂时中止直至完整性检查完成。如果你获得了对某一表的READ LOCAL锁定（与写锁定相对），该表允许在表尾执行并行插入，当其他客户端执行插入操作时，允许执行读操作。新插入的记录不会被有读锁定属性的客户端看到，直至解除了该锁定为止。使用INSERT DELAYED，能够将插入项置于本地队列中，直至锁定解除，不会让客户端等待插入完成。请参见13.2.4.2节，“INSERT DELAYED语法”。

从我们赋与其名称的意义上，“原子”绝非不可思议的。它仅意味着，你能确信在每个特性更新运行的同时，其他用户不能干涉它，而且不会出现自动回滚（如果你不小心，对于事务性表，这种情况可能发生）。MySQL服务器还能保证不存在脏读。

下面列出了使用非事务性表的一些技术：

·         对于需要事务的循环，通常能使用LOCK TABLES进行编码，不需要光标来更新正在处理的记录。

·         要想避免使用ROLLBACK，可采取下述策略：

1.    使用LOCK TABLES锁定所有希望访问的表。

2.    执行更新前，测试必须为真的条件。

3.    如果一切正常，执行更新。

4.    使用UNLOCK TABLES解除锁定。

与使用具有回滚可能性的事务性表相比，它通常具有更快的速度，虽然并非始终如此。该解决方案唯一不能处理的情形是，在更新中途杀死了线程。在这种情况下，将释放所有锁定，但某些更新可能尚未执行。

·         也可以使用函数在单一操作中更新记录。采用下述技术，能获得效率很高的应用程序。

o        根据其当前值更改列。

o        仅更新出现实际变化的列。

例如，当我们更新某些客户信息时，仅更新已更改的客户数据，与原始行相比，仅测试已更改的数据或依赖于已更改数据的数据是否未出现变化。对于已更改数据的测试，它是通过UPDATE语句的WHERE子句完成的。如果记录未更新，将向客户端发出消息： “一些你改变的数据已被其他用户更改”。接下来，我们在窗口中给出了旧行和新行，以便用户决定使用哪个版本。

这给出了与列锁定类似的结果，但效果更好，使用相对于其当前值的值，仅更新了某些列。这意味着，典型的UPDATE语句与下面给出的类似：

UPDATE tablename SET pay_back=pay_back+125;

UPDATE customer

  SET

    customer_date='current_date',

    address='new address',

    phone='new phone',

    money_owed_to_us=money_owed_to_us-125

  WHERE

    customer_id=id AND address='old address' AND phone='old phone';

它很有效，即使其他客户端更改了pay_back或money_owed_to_us列中的值，也能使用。

·         在很多情况下，用户希望将LOCK TABLES和／或ROLLBACK用于管理唯一ID。可以在不使用锁定功能或回滚的情况下，使用AUTO_INCREMENT列以及LAST_INSERT_ID() SQL函数或mysql_insert_id() C API函数，更有效地处理之。请参见12.9.3节，“信息函数”。请参见25.2.3.36节，“mysql_insert_id()”。

我们通常能使用代码来处理行级锁定方面的需求。在某些情况下，实际上不需要它，InnoDB表支持行级锁定。通过MyISAM表，能够在表中使用标志列，并完成类似下面的操作：

UPDATE tbl_name SET row_flag=1 WHERE id=ID;

如果找到行，而且原始行中的row_flag不是1，对于受影响的行数，MySQL返回1。

你可以认为MySQL将前述查询更改为：

UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;

对于MySQL，在5.0版本中实现了存储程序。请参见第20章：存储程序和函数。

从5.0.2版开始，在MySQL中实现了基本的触发器功能，计划在MySQL 5.1中进一步发展它。请参见第21章：触发程序。

在MySQL服务器3.23.44和更高版本中，InnoDB存储引擎支持对外键约束的检查功能，这些约束包括CASCADE、ON DELETE和ON UPDATE。请参见15.2.6.4节，“FOREIGN KEY约束”。

对于InnoDB之外的其他存储引擎，MySQL服务器能够解析CREATE TABLE语句中的FOREIGN KEY语法，但不能使用或保存它。未来将进行扩展，能够将这类信息保存到表规范文件中，以便能被mysqldump和ODBC检索。稍后，还将为MyISAM表实现外键约束。

外键增强为数据库开发人员提供了多项益处：

·         假定关联设计恰当，外键约束使得程序员更难将不一致性引入数据库。

·         数据库服务器具有集中式约束检查功能，因而没有必要在应用程序一侧执行这类检查。这样，就消除了不同应用程序使用不同方式检查约束的可能性。

·         使用级联更新和删除，简化了应用程序代码。

·         设计恰当的外键有助于以文档方式记录表间的关系。

请记住，这些好处是以数据库服务器为执行必要检查而需的额外开销为代价的。服务器额外检查会影响性能，对于某些应用程序，该特性不受欢迎，应尽量避免。（出于该原因，在一些主要的商业应用程序中，在应用程序级别上实施了外键逻辑）。

MySQL允许数据库开发人员选择要使用的方法。如果你不需要外键，并希望避免与强制引用完整性有关的开销，可选择另一种表类型取而代之，如MyISAM。（例如，MyISAM存储引擎为仅执行INSERT和SELECT操作的应用程序提供了极快的性能，这是因为插入能和检索同时进行）。请参见7.3.2节，“表锁定事宜”。

如果你不打算利用引用完整性检查具备的优点，请记住下述要点：

·         不存在服务器端外键关联检查时，应用程序本身必须处理这类关联事宜。例如，将行按恰当顺序插入表时应谨慎，并应避免产生孤立的子记录。必须能够在多记录插入操作期间更正出现的错误。

·         如果ON DELETE是应用程序所需的唯一引用完整性功能，请注意，从MySQL服务器4.0起，可以使用多表DELETE语句，用单一语句从多个表中删除行。请参见13.2.1节，“DELETE语法”。

·         从具有外键的表删除记录时，在缺少ON DELETE的情况下，一种解决方式是为应用程序增加恰当的DELETE语句。实际上，它与使用外键同样快，而且移植性更好。

注意，使用外键在某些情况下会导致问题。

·         外键支持能处理很多引用完整性事宜，但仍需要仔细设计键的关系，以避免循环规则或不正确的级联删除组合。

·         DBA需要创建关联拓扑，这会使从备份中恢复单独表变得困难，该类情形并不罕见。（加载依赖其他表的表时，MySQL允许你临时禁止外键检查，从而降低了该难度）。请参见15.2.6.4节，“FOREIGN KEY约束”。在MySQL 4.1.1以前。重新加载时，mysqldump能够生成自动利用该性能的转储文件。

注意，SQL中的外键用于检查和强制引用完整性，而不是联合表。如果打算用SELECT语句获取多个表的结果，可在表之间执行联合操作：

SELECT * FROM t1, t2 WHERE t1.id = t2.id;

请参见13.2.7.1节，“JOIN语法”。请参见3.6.6节，“使用外键”。

ODBC应用程序常使用不带“ON DELETE ...”的FOREIGN KEY语法来生成自动WHERE子句。

在MySQL服务器5.0版中实现了视图功能（包括可更新视图）。在5.0.1和更高版本中，提供了二进制版的视图功能。请参见第22章：视图。

View（视图）十分有用，它允许用户像单个表那样访问一组关系（表），而且仅允许对它们的这类访问。视图也能限制对行的访问（特定表的子集）。对于列控制的访问，可使用MySQL服务器中的高级权限系统。请参见5.7节，“MySQL访问权限系统”。

在设计视图的过程中，我们的宏伟目标是，在SQL的范围内尽可能与关联数据库系统的“Codd's Rule #6”兼容。“所有理论上可更新的视图，实际上也应是可更新的”。

一些其他SQL数据库采用“--”作为注释开始标志。MySQL服务器采用“#”作为注释起始字符。对于MySQL服务器，也能使用C风格的注释：/*该处为注释*/。请参见9.5节，“注释语法”。

MySQL服务器3.23.3和更高版本支持“--”注释风格，但要求注释后面跟1空格（或控制字符，如新行）。之所以要求使用空格，是为了防止与自动生成SQL查询有关的问题，它采用了类似下面的代码，其中，自动为“!payment!”插入“payment”的值：

UPDATE account SET credit=credit-!payment!

考虑一下，如果“payment”的值为负数如“-1”时会出现什么情况：

UPDATE account SET credit=credit--1

在SQL中“credit--1”是合法的表达式，但是，如果“--1”被解释为注释开始，部分表达式将被舍弃。其结果是，表达式的意义与预期的意义完全不同。

UPDATE account SET credit=credit

该语句不会对值作任何更改！这表明，允许注释以“--”开始会产生严重后果。

采用MySQL服务器3.23.3和更高版本中的这类注释方法，“credit--1”实际上很安全。

另一个安全特性是，mysql命令行客户端将删除所有以“--”开头的行。

仅当使用高于3.23.3的MySQL时，下述信息才有意义：

如果有1个文本文件形式的SQL程序，该文件包含“--”注释，应按下述方式使用replace实用工具，将其转换为使用“#”字符的注释：

shell> replace " --" " #" < text-file-with-funny-comments.sql \

         | mysql db_name

而不是通常的：

shell> mysql db_name < text-file-with-funny-comments.sql

你也可以编辑注释文件，将“--”注释更改为“#”注释：

shell> replace " --" " #" -- text-file-with-funny-comments.sql

使用下述命令将其改回去：

shell> replace " #" " --" -- text-file-with-funny-comments.sql

通常情况下，当你试图INSERT或UPDATE会导致主键、唯一键或外键冲突的行时，将出现错误。如果你正在使用事务性存储引擎时，如InnoDB，MySQL会自动回滚语句。如果你正在使用非事务性存储引擎，MySQL将在出错的行上停止执行语句，剩余的行也不再处理。

如果你希望忽略这类键冲突，可使用MySQL支持的、用于INSERT和UPDATE的IGNORE关键字。在这种情况下，MySQL将忽略任何键冲突，并继续处理下一行。请参见13.2.4节，“INSERT语法”。请参见3.2.10节，“UPDATE语法”。

使用mysql_info() C API函数，能够获取关于实际插入或更新行数的信息。请参见25.2.3.34节，“mysql_info()”。在MySQL 4.1和更高版本中，也能使用SHOW WARNINGS语句。请参见13.5.4.22节，“SHOW WARNINGS语法”。

目前，只有InnoDB表支持外键。请参见15.2.6.4节，“FOREIGN KEY约束”。计划在MySQL 5.1中实施对MyISAM表的外键支持。

在MySQL 5.0.2之前，MySQL对非法或不当值并不严厉，而且为了数据输入还会强制将它们变为合法值。在MySQL 5.0.2和更高版本中，保留了以前的默认行为，但你可以为不良值选择更传统的处理方法，从而使得服务器能够拒绝并放弃出现不良值的语句。本节介绍了MySQL的默认行为（宽大行为），新的严格的SQL模式，以及它们的区别。

如果你未使用严格模式，下述情况是真实的。如果将“不正确”的值插入到列，如将NULL值插入非NULL列，或将过大的数值插入数值列，MySQL会将这些列设置为“最可能的值”，而不是生成错误信息。

·         如果试图将超范围的值保存到数值列，MySQL服务器将保存0（最小的可能值）取而代之，或最大的可能值。

·         对于字符串，MySQL或保存空字符串，或将字符串尽可能多的部分保存到列中。

·         如果打算将不是以数值开头的字符串保存到数值列，MySQL将保存0。

·         MySQL允许将特定的不正确日期值保存到DATE和DATETIME列（如“2000-02-31”或“2000-02-00”）。其观点在于，验证日期不是SQL服务器的任务。如果MySQL能保存日期值并准确检索相同的值，MySQL就能按给定的值保存它。如果日期完全不正确（超出服务器能保存的范围）将在列中保存特殊的日期值“0000-00-00”取而代之。

·         如果试图将NULL值保存到不接受NULL值的列，对于单行INSERT语句，将出现错误。对于多行INSERT语句或INSERT INTO ... SELECT语句，MySQL服务器会保存针对列数据类型的隐含默认值。一般情况下，对于数值类型，它是0，对于字符串类型，它是空字符串('')，对于日期和时间类型是“zero”。在13.1.5节，“CREATE TABLE语法”一节中，讨论了隐含的默认值。

·         如果INSERT语句未为列指定值，如果列定义包含明确的DEFAULT子句，MySQL将插入默认值。如果在定义中没有这类DEFAULT子句，MySQL会插入列数据类型的隐含默认值。

采用前述规则的原因在于，在语句开始执行前，无法检查这些状况。如果在更新了数行后遇到这类问题，我们不能仅靠回滚解决，这是因为存储引擎可能不支持回滚。中止语句并不是良好的选择，在该情况下，更新完成了“一半”，这或许是最差的情况。对于本例，较好的方法是“仅可能做到最好”，然后就像什么都未发生那样继续。

在MySQL 5.0.2和更高版本中，可以使用STRICT_TRANS_TABLES或STRICT_ALL_TABLES SQL模式，选择更严格的处理方式。请参见5.3.2节，“SQL服务器模式”。

STRICT_TRANS_TABLES的工作方式：

·         对于事务性存储引擎，在语句中任何地方出现的不良数据值均会导致放弃语句并执行回滚。

·         对于非事务性存储引擎，如果错误出现在要插入或更新的第1行，将放弃语句。（在这种情况下，可以认为语句未改变表，就像事务表一样）。首行后出现的错误不会导致放弃语句。取而代之的是，将调整不良数据值，并给出告警，而不是错误。换句话讲，使用STRICT_TRANS_TABLES后，错误值会导致MySQL执行回滚操作，如果可以，所有更新到此为止。

要想执行更严格的检查，请启用STRICT_ALL_TABLES。除了非事务性存储引擎，它与STRICT_TRANS_TABLES等同，即使当不良数据出现在首行后的其他行，所产生的错误也会导致放弃语句。这意味着，如果错误出现在非事务性表多行插入或更新过程的中途，仅更新部分结果。前面的行将完成插入或更新，但错误出现点后面的行则不然。对于非事务性表，为了避免这种情况的发生，可使用单行语句，或者在能接受转换警告而不是错误的情况下使用STRICT_TRANS_TABLES。要想在第1场合防止问题的出现，不要使用MySQL来检查列的内容。最安全的方式（通常也较快）是，让应用程序负责，仅将有效值传递给数据库。

有了严格的模式选项后，可使用INSERT IGNORE或UPDATE IGNORE而不是不带IGNORE的INSERT或UPDATE，将错误当作告警对待。

ENUM和SET列提供了定义仅能包含给定值集合的列的有效方式。但是，从MySQL 5.0.2起，ENUM和SET不是实际约束。其原因与不重视NOT NULL的原因一样。请参见1.8.6.2节，“对无效数据的约束”。

ENUM列总有1个默认值。如果未指定默认值，对于包含NULL的列，默认值为NULL；否则，第1个枚举值将被当作默认值。

如果在ENUM列中插入了不正确的值，或者，如果使用IGNORE将值强制插入了ENUM列，会将其设置为保留的枚举值0，对于字符串情形，将显示为空字符串。请参见11.4.4节，“ENUM类型”。

如果在SET列中插入了不正确值，该值将被忽略。例如，如果列能包含值“a”、“b”和“c”，并赋值“a,x,b,y”，结果为“a,b”。请参见11.4.5节，“SET类型”。

从5.0.2开始，可以对服务器进行配置，以使用严格的SQL模式。请参见5.3.2节，“SQL服务器模式”。启用严格模式后，ENUM或SET列的定义可作为对输入至列的值的约束。如果值不满足下述条件，将出现错误：

·         ENUM值必须是在列定义中给出的值之一，或内部的数字等同物。该值不能是错误值（即，0或空字符串）。对于定义为ENUM('a','b','c')的列，诸如''、'd'和'ax'等，均是非法的，并将被拒。

·         SET值必须是空字符串，或由1个或多个在列定义中给出的且用逗号隔开的值组成。 对于定义为SET('a','b','c')的列，诸如'd'和'a,b,c,d'等，均是非法的，并将被拒。

如果使用了INSERT IGNORE或UPDATE IGNORE，在严格模式下，可抑制无效值导致的错误。在这种情况下，将生成警告而不是错误。对于ENUM，值将作为错误成员(0)插入。对于SET，会将给定值插入，但无效的子字符串将被删除。例如，'a,x,b,y'的结果是'a,b'，就像前面介绍的那样。