本节介绍其他数据库中有而MySQL中无的功能。它介绍省略了什么功能，以及在需要这些功能时怎么办。一般情况下， MySQL之所以忽略某些功能是因为它们有负面性能影响。有的功能正在开发者的计划清单上，一旦找到一种方法可以实现相应的功能而又不致于影响
良好性能的目标，就会对它们进行实现。
■ 子选择。子选择是嵌套在另一个SELECT 语句内的SELECT 语句，如下面的查询所示：
SELECT * FROM score
WHERE event_id IN (SELECT event_id FROM event WHERE type = "T")
子选择打算在MySQL3.24 中给出，到那时它们就不会忽略了。但到那时，许多用子选择撰写的查询也可以用连接来编写。请参阅3 . 8 . 1节“将子选择编写为连接”。
■ 事务处理和提交/回退。事务处理是由其他客户机作为一个整体不中断执行的一组SQL语句。提交/回退功能允许规定数条语句作为一个整体执行或不执行。即，如果事务处理中的任何一条语句失败，那么直到该语句前执行的所有语句的作用都被撤消。
ySQL 自动进行单一SQL 语句的同步以免客户机互相干扰。（例如，两个客户机不能对相同的表进行同时写入。）此外，可利用LOCK TABLES 和UNLOCK TABLES将数条语句组成一个整体，这使您能够完成单条语句的并发控制所不能满足的操作。MySQL与事务处理有关的问题是，它不能自动对数条语句进行组织，而且如果这些语句中有某一条失败后也不能对它们进行回退。
为了弄清事务处理为什么有用，可举例说明。假如您在服装销售业工作，无论何时，只要您的销售人员进行了一次销售，都要更新库存数目。下面的例子说明了在多个销售人员同时更新数据库时可能出现的问题（假如初始的衬衫库存数目为4 7）：
t1销售人员1卖出3件衬衫
t2 销售人员检索当前衬衫计数（ 4 7）：
SELECT quantity FROM inventory WHERE item = "shirt"
t3 销售人员2卖出2件衬衫
t4 销售人员2检索当前衬衫计数（ 4 7）
SELECT quantity FROM inventory WHERE item = "shirt"
t5 销售人员1计算库存的新数目为47 - 3 = 44 并设置衬衫计数为44：
UPDATE inventory SET quantity = 44 WHERE item = "shirt"
t6 销售人员2计算库存的新数目为47 - 2 = 45 并设置衬衫计数为45：
UPDATE inventory SET quantity = 45 WHERE item = "shirt"
在这个事件序列结束时，您已经卖掉了5 件衬衫，但库存数目却是45 而不是4 2。问题是如果在一条语句中查看库存而在另一条语句中更新其值，这是一个多语句的事务处理。第二条语句中所进行的活动取决于第一条语句中检索出的值。但是如果在重叠的时间范围内出现独立的事务处理，则每个事务处理的语句会纠缠在一起，并且互相干扰。在事务处理型的数据库中，每个销售人员的语句可作为一个事务处理执行，这样，销售人员2 的语句在销售人员1的语句完成之前不会被执行。在MySQL中，可用两种方法达到这个目的：
■ 方法1：作为一个整体执行一组语句。可利用LOCK TABLES 和UNLOCK TABLES将语句组织在一起，并将它们作为一个原子单元执行：锁住所需使用的表，发布查询，然后释放这些锁。这样阻止了其他人在您锁住这些表时使用它们。利用表同步，库存情况如下所示：
t1销售人员1卖出3件衬衫
t2 销售人员1请求一个锁并检索当前衬衫计数（47）
LOCK TABLES inventory WRITE
SELECT quantity FROM inventory WHERE item = "shirt"
t3 销售人员2卖出2件衬衫
chentong 于 2005-12-27 09:36:57发表:
■ 外部键和引用完整性。外部键允许定义一个表中的键与另一个表中的键相关，而引用完整性允许放置对包含外部键的表可以做什么的约束。例如， samp_db 样例数据库的score 表中包含一个student_id 列，我们用它来将学分记录关联到student 表中的学生。score.student_id 将定义为支持此概念的数据库中的一个外部键，我们将在其上加上一条约束，使不能为student 表中不存在的学生输入学分记录。此外，应该允许级联删除，以便如果某个学生从student 表中被删除后，该学生的任何学分记录将会自动地从
score 表中删除。
外部键有助于保持数据的一致性，而且还提供了某种方便的手段。MySQL不支持外部键的原因主要是由于它对数据库的实现与维护有负作用。（MySQL参考指南详细列出了这些原因。）注意，对于外部键的这种看法与其他数据库文献中的看法有些不同，有的数据库文献通常将它们描述成“基本的”。MySQL的开发者并不赞同这个观点。如果您赞成，那么最好是考虑采用其他提供外部键支持的数据库。如果数据具有特别复杂的关系，您可能不希望担负在应用程序中实现这些相关性的工作。（即使这样做的工作量要比增加几个额外的DELETE 语句的工作量要稍少一些。）除了在一定程度上能够在CREATE TABLE 语句中分析FOREIGN KEY 子句外，MySQL不支持外部键。（这有助于使从其他数据库移植代码到MySQL更为容易。）MySQL不强制让外部键作为一种约束，也不提供级联删除功能。
外部键强制实施的约束一般不难用程序逻辑来实现。有时，它只是一个怎样进行数据录入处理的问题。例如，为了将一个新记录插入score 表，不太可能插入不存在的学生的学分。显然，输入一组学分的方法应该是根据从student 表得出的学生名单，对每个学生，取其学分并利用该学生的ID 号产生一个score 表的记录。对于这个过程，不存在录入一个不存在的学生的记录的可能。您不会凭空造出一个学分记录来插入score 表。要实现DELETE 的级联效果，必须用自己的应用程序逻辑来完成。假如想要删除13 号学生。这也隐含表示需要删除该学生的学分记录。在支持级联删除的数据库中，只需要用如下的语句就可以删除student 表的记录和相应的score 表的记录：
DELETE FROM student WHERE student_id = 13
而在MySQL中，必须明确地用DELETE 语句自己进行第二个删除语句：
DELETE FROM student WHERE student_id = 13
DELETE FROM score WHERE student_id = 13
■ 存储过程和触发器。存储过程是编译和存放在服务器中的SQL 代码。它可在以后调用而无需从客户机发送并分析。可以对一个过程进行更改以影响使用它的任何客户机应用程序。触发器功能使一个过程在某个事件发生时被激活，如从表中删除某个记录时，激活相应的过程。例如，某个作为累计成分的记录被删除时，应该重新进行累计，使累计数反映最新情况。存储过程语言已列入了MySQL准备实现的计划。
■ 视图。视图是一个逻辑概念，其功能像表但本身不是表。它提供了一种查看不同表中的列的途径，在查看时好像这些列属于同一个表一样。视图有时也称为虚表。MySQL也准备实现视图功能。
■ 记录级权限和锁定。MySQL支持各种权限，从全局权限到数据库、表、列的权限。但它不支持记录级的权限。不过，可在应用程序中利用GET_LOCK( ) 和R E L E A S E _LOCK( ) 函数来实现协同记录锁。这个过程在附录C“运行算符和函数参考”中相应的项目下介绍。
■ “- -”作为注释的开始。MySQL不支持这种注释风格，因为它是一个有歧义的结构，虽然自MySQL3.23 以来，注释可用两个短划线加一个空格开始。更详细的信息，请参阅3 . 7节“加注释”。
chentong 于 2005-12-27 09:36:14发表:
t4 销售人员2试图取得一个锁：这被阻塞，因为销售人员1已经占住了锁：
LOCK TABLES inventory WRITE
t5 销售人员1计算库存的新数目为47 - 3 = 44 并设置衬衫计数为44，然后释放锁：
UPDATE inventory SET quantity = 44 WHERE item = "shirt"
UNLOCK TABLES
t6 现在销售人员2的锁请求成功。销售人员2检索当前衬衫计数（ 44）
SELECT quantity FROM inventory WHERE item = "shirt"
t7 销售人员2计算库存的新数目为44 - 2 = 42，设置衬衫计数为4 2，然后释放锁：
UPDATE inventory SET quantity = 42 WHERE item = "shirt"
UNLOCK TABLES
现在来自两个事务处理的语句不混淆了，并且库存衬衫数也正确进行了设置。我们在这里使用了一个WRITE 锁，因为我们需要修改inventory 表。如果只是读取表，可使用READ 锁。当您正在使用表时，这个锁允许其他客户机读取表。在刚才举的例子中，销售人员2大概不会注意到执行速度上的差异，因为其中的事务处理都很短，执行速度很快。但是，作为一个具有普遍意义的规则，那就是应该尽量避免长时间地锁住表。
如果您正在使用多个表，那么在您执行成组查询之前，必须锁住他们。如果只是从某个特定的表中读取数据，那么只需给该表加一个读出锁而不是写入锁。假如有一组查询，其中想对inventory 表作某些更改，而同时需要从customer 表中读取某些数据。在此情形下，inventory 表上需要一个写入锁，而customer 表上需要一个读出锁：
LOCK TABLES inventory WRITE,customer READ
...
UNLOCK TABLES
这里要求您自己对表进行加锁和解锁。支持事务处理的数据库系统将会自动完成这些工作。但是，在作为一个整体执行的分组语句方面，无论在是否支持事务处理的数据库中都是相同的。
■ 方法2：使用相对更新而不是绝对更新。要解决来自多个事务处理的语句混淆问题，应消除语句之间的依赖性。虽然这样做并不都总是可能的，它只针对我们的库存例子可行。对于方法1中所用的库存更新方法，其中事务处理需要查看当前库存数目，并依据销售衬衫的数目计算新值，然后更新衬衫的数目。有可能通过相对于当前衬衫数目进行计数更新，在一个步骤中完成工作。如下所示：
t1销售人员1卖出3件衬衫
t2 销售人员1将衬衫计数减3：
UPDATE inventory SET quantity = quantity - 3 WHERE item = "shirt"
t3 销售人员2卖出2件衬衫
t4 销售人员2将衬衫计数减2：
UPDATE inventory SET quantity = quantity - 2 WHERE item = "shirt"
因此，这里根本不需要多条语句的事务处理，从而也不需要锁住表以模拟事务处理功能。如果所使用的事务处理类型与这里类似，那么就可以不用事务处理也能完成工作。上面的例子说明了在特殊情形下怎样避免对事务处理功能的需求。但这并不是说不存在那种确实需要事务处理功能的场合。典型的例子是财务转账，其中钱从一个账户转到另一个账户。假如Bill 给Bob 开了一张$100 的支票，Bob 兑现了这张支票。Bill 的户头上应该减掉$100 而Bob 的户头上应该增加相同数量的钱：
UPDATE account SET balance = balance -100 WHERE name = "Bill"
UPDATE account SET balance = balance +100 WHERE name = "Bob"
如果在这两条语句执行中，系统发生了崩溃，此事务处理就不完整了。具有真正事务处理和提交/回退功能的数据库系统能够处理这种情况（至少从理论上能够处理。您可能仍然必须判断遇到了哪些事务处理并重新发布它们，但至少不会担心事务只处理了一半）。在MySQL中，系统崩溃时可通过检查更新日志来判断事务处理的状态，虽然这可能需要对日志进行某种手工检查。