MyISAM 存储引擎只支持表锁，这也是 MySQL 开始几个版本中唯一支持的锁类型。随着应用对事务完整性和并发性要求的不断提高，MySQL 才开始开发基于事务的存储引擎，后来慢慢出现了支持页锁的 BDB 存储引擎和支持行锁的 InnoDB 存储引擎。但是 MylSAM 的表锁依然是使用最为广泛的锁类型。

查询表级锁争用情况

可以通过检查 table_locks_waited 和 table_locks_immediate 状态变量来分析系统上的表锁定争夺：

show status like 'table%'

如果 Table_locks_waited 的值比较高，则说明存在着较严重的表级锁争用情况。

MySQL表级锁的锁模式

MySQL的表级锁有两种模式：表共享读锁 (Table Read Lock)和表独占写锁(Table WritLock )。对 MyISAM 表的读操作，不会阻塞其他用户对同一表的读请求，但会阻塞对同表的写请求；对 MyISAM 表的写操作，则会阻塞其他用户对同一表的读和写操作；当一个线程获得对一个表的写锁后、只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待，直到锁被释放为止。

如何加表锁

MyISAM 在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行更新操作（UPDATE，DELETE、INSERT等)前，会自动给涉及的表加写锁，这个过程并不需要用户干预。如果用户想要显示加锁，可通过以下语句加锁：

-- 加写锁
lock table tableName write;

-- 加读锁
lock table talbeName read [local];

-- 释放锁
unlock tables;

"local"选项的作用是在满足MySIAM表并发插入条件的情况下，允许其他用户在表尾并发插入记录。

MyISAM存储引擎有一个系统变量 concurrent_insert，专门用以控制其并发插人的行为，其值分别可以为0、1或2。

1. 当concurrent_insert设置为0时，不允许并发插入。
2. 当concurrent_insert设置为1时，如果MyISAM表中没有空洞（即表的中间没有被删除的行1），MyISAM 允许在一个进程读表的同时，另一个进程从表尾插入记录，这也是MySQL的默认设置。
3. 当concurrent_insert设置为2时，无论MyISAM表中有没有空洞，都允许在表尾并发插入记录。

可以利用MyISAM存储引擎的并发插入特性来解决应用中对同一表查询和插入的锁争用。例如，将concurrent_insert系统变量设为2，总是允许并发插入；同时，通过定期在系统空闲时段执行OPTIMIZE TABLE语句来整理空间碎片，回收因删除记录而生产的空洞。

MylSAM的锁调度

MyISAM存储引擎的读锁和写锁是互斥的，读写操作是串行的。那么，一个进程请求某个MyISAM表的读锁，同时另一个进程也请求同一表的写锁，MySOL 如何处理呢？答案是写进程先获得锁。不仅如此，即使读请求先到锁等待队列，写请求后到，写锁也会插到读锁请求之前！

这是因为MySOL认为写请求一般比读请求要重要。这也正是MyISAM表不太适合于有大量更新操作和查询操作应用的原因，因为，大量的更新操作会造成查询操作很难获得读锁，从而经常阻塞。这种情况有时可能会变得非常糟糕！幸好我们可以通过一些设置来调节MyISAM的调度行为。

1. 通过指定启动参数 low-priority-updates，使MyISAM 引擎默认给予读请求以优先的权利。
2. 通过执行命今SET LOW_PRIORITY_UPDATES=l，使该连接发出的更新请求优先级降低。
3. 通过指定INSERT、UPDATE、DELETE 语句的 LOW_PRIORITY属性，降低该语的优先级。
4. MySOL也提供了一种折中的办法来调节读写冲突，即给系统参数 max _write_lock_count 设置一个合适的值，当一个表的读锁达到这个值后，MySQL就暂时将写请求的优先级低，给读进程一定获得锁的机会。

一些需要长时间运行的查询操作，也会使写进程“饿死”！因此，应用中应尽量避免出现长时间运行的查询操作，不要总想用一条 SELECT 语句来解决问题，因为这种看似巧妙的 SQL 语句，往往比较复杂，执行时间较长，在可能的情况下可以通过使用中间表等措施对 SQL 语句做一定的“分解”，使每一步查询都能在较短时间完成，从而减少锁冲突。如果复杂查询不可避免，应尽景安排在数据库空闲时段执行，比如一些定期统计可以安排在夜间执行。