锁的层次和并发性
前面讨论的调度调节符允许你改变默认的调度策略。其中的大部分内容都是介绍使用这些调节符来解决数据表层次(table-level)的锁引起的问题，这都是MyISAM和MEMORY存储引擎用来管理数据表争用的问题的。
BDB和InnoDB存储引擎实现了不同层次的锁，所以其性能特征和对争用的管理是不同的。BDB引擎使用页面层次(page-level)的锁。InnoDB引擎使用数据行层次(row-level)的锁，但是只在必要的时候使用(在很多情况下，例如当读取操作都完成的时候，InnoDB可能根本就不使用锁)。
存储引擎使用的锁的层次对客户端的并发操作有很大的影响。假设两个客户端都希望更新某个数据表中的一行。由于要执行更新，每个客户端都需要一个写入锁。对于MyISAM数据表，引擎会为第一个客户端分配一个锁，这会引起第二个客户端阻塞，直到第一个客户端完成操作。对于BDB数据表，它可以实现更大的并发性：两个更新操作会同步进行，除非两个数据行都位于同一个页面中。在InnoDB数据表中，并发性更高;只要两个客户端没有更新同一行，两个更新操作就能同时发生。
一般的规则是，锁的层次越细微，并发性越好，因为只要客户端使用数据表的部分不同，那么使用表的客户端就可以更多。它实际暗示着不同的存储引擎适合于不同的语句混合(mixes)：
MyISAM检索的速度非常快。但是使用表层次的锁可能成为混合的检索和更新环境中的问题，特别是检索倾向于长时间运行的时候。在这些条件下，更新可能需要等待很久才能进行。
当更新操作很多的时候，BDB和InnoDB数据表可以提供更好的性能。由于锁在页面或数据行层次进行，表被锁定的范围较小。这会减少锁的争用，提高并发性。
在防止死锁(deadlock)方面，表层次的锁比细微层次的锁更有优势。使用表层次的锁的时候，死锁不会发生。服务器可以通过查看语句来检测需要的数据表，并提前锁定它们。而InnoDB和BDB数据表会发生死锁，因为这些存储引擎没有在事务开始的时候分配所有必要的锁。作为代替，在事务处理的过程中，当检测到需要锁的时候才分配。这就可能出现两个语句获取了锁，接着试图进一步获取锁(需要多个锁)，但是这些锁却被对方保持着，等待对方释放。其结果是每个客户端都拥有一个锁，同时还需要利用其它的客户端拥有的锁才能继续执行。这会导致死锁，服务器必须终止其中一个事务。
