前言
锁是计算机协调多个进程或线程并发访问某一资源的机制，在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问的一个重要因素。
MySQL表概述
相比其他数据库而言，MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。
MySQL这3种锁的特性大致归纳如下
- 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生所冲突的概率最高，并发度最低。
- 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生所冲突的概率最低，并发度最高。
- 页面锁：开销和加锁时间介于表锁和行锁之间；会出现死锁；锁定粒度介于表锁和行锁之间，并发度一般。
从上述特点可见，很难笼统地说哪种锁更好，只能就具体应用的特点来说哪种锁更合适！仅从锁的角度来说，表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少不同的数据，同时又有并发查询的应用，如一些在线事务处理（OPTP）系统。
MyISAM表锁
MyISAM存储引擎只支持表锁，这也是MySQL开始几个版本中唯一支持的锁类型。随着应用跟对事物完整性和并发性要求的不断提高，MySQL才开始开发基于事务的存储引擎，后来慢慢出现了支持页锁的BDB存储引擎和支持行锁的InnoDB存储引擎。但是MyISAM的表锁依然是使用最为广泛的锁类型。
查询表级锁的争用情况：可以通过检查Table_locks_waited和Table_locks_immediate状态变量来分析系统上的表锁定争夺：
mysql> show status like 'table%'; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | Table_locks_immediate | 118 | | Table_locks_waited | 0 | | Table_open_cache_hits | 5 | | Table_open_cache_misses | 3 | | Table_open_cache_overflows | 0 | +----------------------------+-------+ 5 rows in set (0.00 sec)
如果Table_locks_waited的值比较高，则说明存在着较严重的表级锁争用情况。
MySQL表级锁的锁模式
MySQL的表级锁有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）。锁模式的兼容性如下表所示。
| 当前模式是否兼容请求锁模式 | None | 读锁 | 写锁 |
|---|---|---|---|
| 读锁 | 是 | 是 | 否 |
| 写锁 | 是 | 否 | 否 |
可见，对MyISAM表的读操作，不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求；对MyISAM表的写操作，则会阻塞其他用户对同一表的度和写操作；MyISAM表的读写操作之间，以及写操作之间是串行的。
如何加表锁
MyISAM在执行查询语句（select）前，会自动给涉及的所有表加读锁，在执行更新操作（update、delete、insert等）前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此，用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁。
给MyISAM表显式加锁，一般是为了在一定程度模拟事务操作，实现对某一时间点多个表的一致性读取。例如，有个订单表orders，其中记录有个订单的总金额total，同时还有一个订单明细表order_detail，其中记录有个订单每一产品的金额小计subtotal，假设需要查找这两个表的额金额合计是否相符，可能就需要执行如下两条SQL语句：
select sum(total) from orders; select sum(subtotal) from order_detail;
这是，如果不先给两个表加锁，就可能产生错误的结果，因为地一条语句执行过程中，order_detail表可能已经发生了改变，因此，正确的方法应该是：
Lock tables orders read local, order_detail read local; select sum(total) from orders; select sum(subtotal) from order_detail; Unlock tables;
- 以上的例子在LOCK TABLES时加了“local”选项，其作用就是在满足MyISAM表并发插入条件的情况下，允许其他用户在表尾并发插入记录；
- 在用LOCK TABLES给表显式加表锁时，必须同时取得所有涉及表的锁，并且MySQL不支持锁升级，也就是说，在执行LOCK TABLES后，只能访问显式加锁的这些表，不能访问未加锁的表；同时，如果加的是读锁，那么只能执行查询操作，而不能执行更新操作。在自动加锁的情况下也是如此，MyISAM总是一次获得SQL语句所需要的全部锁，这也正是MyISAM表不会出现死锁（Deadlock Free）的原因。
并发插入（Concurrent Inserts）
前面提到的MyISAM表的读和写是串行的，但这是就总体而言的，在一定条件下，MyISAM表也支持查询和插入操作的并发进行。
MyISAM存储引擎有一个系统变量concurrent_insert，专门用以控制其并发插入的行为，其值分别可以为0、1或2.
- 当concurrent_insert设置为0时，不允许并发插入。
- 当concurrent_insert设置为1时，如果MyISAM表中没有空洞（即表的中间没有被删除的行），MyISAM允许在一个进程读表的同时，另一个进程从表尾插入记录，这也是MyISAM的默认设置。
- 当concurrent_insert设置为2时，无论MyISAM表中有没有空洞，都允许在表尾并发插入记录。
MyISAM的锁调度
由于MyISAM存储引擎的读锁和写锁是互斥的，读写操作是串行的。那么一个进程该请求某个MyISAM表的读锁，同时另一个进程也请求同一表的写锁，MySQL如何处理呢？答案是写进程先获得锁。不仅如此，即使读请求先到锁等待队列，写请求后到，写锁也会插到读锁之前！这是因为MySQL认为写请求一般比读请求要重要。这也正是MyISAM表不大适合于有大量更新操作和查询操作应用的原因，因为，大量的更新操作会造成查询操作很难获得读锁，从而可能永远阻塞。这种情况有可能就会变得非常糟糕！幸好可以通过一些设置来调节MyISAM的调度行为。
- 通过指定启动参数low-priority-updates，使MyISAM引擎默认给予读请求以优先的权利。
- 通过执行命令SET LOW_PRIORITY_UPDATES=1,是该连接发出的更新请求优先级降低。
- 通过指定INSERT、UPDATE、DELETE语句的LOW_PRIORITY属性，降低该语句的优先级。
虽然以上3种方法都是要么更新优先，要么查询优先的方法，但还是可以用其来解决查询相对重要的应用（如用户登录系统）中读锁等待严重的问题。
另外，MySQL也提供了一种折中的方法来调节读写冲突，即给系统参数max_write_lock_count设置一个合适的值，当一个表的读锁达到这个之后，MySQL就暂时将写请求的优先级降低，给读进程一定获得锁的机会。
小结
以上说明了写优先调度机制带来的问题和解决办法，这里还要强调一点：一些需要长时间运行的查询操作，也会使写进程“饿死”！因此，应用中应尽量避免出现长时间运行的查询操作，不要总想用一条select语句来解决问题，因为这种看似巧妙的SQL语句，往往比较复杂，执行时间较长，在可能的情况下可以通过使用中间表等措施对SQL语句做一定的“分解”，是每一步查询都能在较短时间完成，从而减少锁冲突。如果复杂查询不可避免，应尽量安排在数据库空闲时段执行，比如一些定期统计可以安排在夜间执行。