3.9 MySQL不支持的功用
    本节引见其他数据库中有而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件衬衫
    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"
    因此，这里基本不需求多条语句的事务处理，从而也不需求锁住表以模仿事务处理功用。如果所使用的事务处理类型与这里类似，那么就可以不用事务处理也能完成任务。上面的例子说明了在特殊情形下怎样避免对事务处理功用的需求。但这并不是说不存在那种