锁
一、概念
锁是计算机协调多个进程或线程访问某一个资源的机制。在数据库中，除传统的计算资源（CPU、RAM、IO）的争用意外，数据也是一种许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问的一个重要因素。从这个角度来说，锁对数据库尤其重要，也更加复杂。本文就以MyISAM和InnoDB两个引擎来说明锁的问题；
二、MySQL锁概述
相对其他数据库而言，MySQL的锁机制比较简单，其中最为显著的特点是不同的引擎具有不同的锁。比如MyISAM和InnoDB分别采用表锁、行锁，但是InnoDB也支持表锁，默认情况下采用行锁；
三、MySQL表锁和行锁对比
| 锁的名称 | 开销 | 加锁速度 | 死锁 | 粒度 | 并发性能 |
| 表锁 | 小 | 快 | 不会出现 | 大 | 最低 |
| 行锁 | 大 | 慢 | 出现 | 小 | 最高 |
从锁的角度来说表锁适合查询为主，只有少量按索引条件更新数据的应用；行锁适合于大量按索引条件来并发更新少量的数据，同时又有并发查询的应用；
MyISAM表锁
一、查询表级锁的争用情况
可以通过table_locks_waited和table_locks_immediate来分析系统表锁的争夺；
如果table_locks_waited的值比较高的话，则说明存在较高的表锁争夺。
二、表锁的锁模式
表级锁有两种方式：读锁和写锁，锁模式的兼容性如下:
| 请求锁模式是否兼容当前锁模式 | 读锁 | 写锁 |
| 读锁 | 是 | 否 |
| 写锁 | 否 | 否 |
由上表可见，MyISAM表的读操作是不会阻塞其他用户对同一张表的读请求，但会阻塞表的写请求；对于MyISAM的写操作，则会阻塞其他用户对同一张表的读和写操作。MyISAM的读和写操作之间，写操作和写操作之间是串行的。也就是说当一个线程获得一个表的写锁之后，只有持有锁的线程可以执行更新操作，其他线程的读和写都要等待，直到锁被释放为止。
三、如何加表锁
MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行更新操作（UPDATE、DELETE、INSERT等）前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此，用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁。
给MyISAM表加显示锁，一般是在一定程度上模拟事务操作，实现某一时间点多个表大的一致性读取。例如我们现在有一个库存表和入库单表，我们要判断入库单的总数是否和库存表的一致，这个时候我们不给这两个表加锁，就可能产生错误的结果，比如在执行第一次查询库存的时候，入库单表发生了改变。这个时候就造成数据错误。
对以上的列子做出总结：
1、上面的例子在LOCK TABLES时加了“local”选项，其作用就是在满足MyISAM表并发插入条件的情况下，允许其他用户在表尾并发插入记录；
2、在用LOCK TABLES给表显式加表锁时，必须同时取得所有涉及到表的锁，并且MySQL不支持锁升级。也就是说，在执行LOCK TABLES后，只能访问显式加锁的这些表，不能访问未加锁的表；同时，如果加的是读锁，那么只能执行查询操作，而不能执行更新操作。其实，在自动加锁的情况下也基本如此，MyISAM总是一次获得SQL语句所需要的全部锁。这也正是MyISAM表不会出现死锁的原因。
四、并发插入
MyISAM的存储引擎有一个系统的变量concurrent_insert，专门用于控制并发插入的行为，其值分别是0,1,2：
1、 当concurrent_insert设置为0时，不允许并发插入。
2、 当concurrent_insert设置为1时，如果MyISAM表中没有空洞（即表的中间没有被删除的行），MyISAM允许在一个进程读表的同时，另一个进程从表尾插入记录。这也是MySQL的默认设置。
3、当concurrent_insert设置为2时，无论MyISAM表中有没有空洞，都允许在表尾并发插入记录。
五、MyISAM的锁调度
MyISAM的存储引擎的读锁和写锁互斥的，读写操作都是串行的。比如现在有一个进程某一个表的读锁，这是同时有个进程来请求同一张表的写锁，这个时候MyISAM表会怎么做呢？结果就是写锁先获取，不仅如此，如果读锁先进入队列，写锁后进入队列，这个时候也是写锁现货的。这是因为MySQL认为写比读重要。这也正是MyISAM表不太合适有大量更新操作和查询操作的原因。因为大量的更新操作是的读操作难以获得锁，从而可能永远阻塞，这种情况可能会变的非常糟糕。但是我们可以设置MyISAM的调度行为
六、什么时候用表锁
1、事务需要更新大部分或全部数据，表又比较大，如果使用默认的行锁，不仅这个事务执行效率低，而且可能造成其他事务长时间锁等待和锁冲突，这种情况下可以考虑使用表锁来提高该事务的执行速度。
2、事务涉及多个表，比较复杂，很可能引起死锁，造成大量事务回滚。这种情况也可以考虑一次性锁定事务涉及的表，从而避免死锁、减少数据库因事务回滚带来的开销。
InnoDB锁
InnoDB和MyISAM的区别是，InnoDB支持事务和行级锁。行级锁和表锁有很多不同的地方，事务的引入也带来了一些新的问题。
一、事务
1、事务的特性
原子性：对数据的修改，要么全部成功，要么全部失败。
一致性：在事务开始的时候和完成的时候，数据都必须保持一致的状态。
隔离性：保证事务在不受外部并发操作影响的“独立”环境执行。也就是事务处理过程的中间部分是不可见的。
持久性：事务完成之后，他对数据的修改是永久的，即系统出现故障也可以保持。
2、并发事务带来的问题
更新丢失:最后的更新覆盖了其他事务所做的更新。解决此问题的条件是，当前用户在没有提交事务的时候，其他用户是不可以操作的。
脏读：一个事务正在对一条记录做修改，这个事务在完成提交前，这个时候另一个事务来读取这一行的数据，就有可能读到脏数据。
不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被删除了！
幻度：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据。
3、事务的隔离级别
a、更新丢失通常应该完全可以避免，但防止更新丢失，不能单靠数据库事务控制来解决，需要应用程序对更新的数据加锁来解决；
b、“脏读”、“不可重复读”和“幻读”，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决
| 隔离级别 | 读数据一致性 | 脏读 | 不可重复读 | 幻读 |
| 未提交读（Read uncommitted） | 最低级别，只能保证不读取物理上损坏的数据 | 是 | 是 | 是 |
| 已提交度（Read committed） | 语句级 | 否 | 是 | 是 |
| 可重复读（Repeatable read） | 事务级 | 否 | 否 | 是 |
| 可序列化（Serializable） | 最高级别，事务级 | 否 | 否 | 否 |
4、InnoDB的行锁模式和加锁方法
| 锁类型 | 可读（其他事务） | 可写（其他事务） |
| 共享锁（S） | 是 | 否 |
| 排他锁（x） | 否 | 否 |
为了行锁和表锁共从，InnoDB又提供了两个意向锁（也就是表锁）
意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。
这四种锁之间的兼容性如下：
| 锁模式 | S | X | IS | IX |
| S | 兼容 | 冲突 | 兼容 | 冲突 |
| X | 冲突 | 冲突 | 冲突 | 冲突 |
| IS | 兼容 | 冲突 | 兼容 | 兼容 |
| IX | 冲突 | 冲突 | 兼容 | 兼容 |
如果一个事务请求的锁模式与当前的锁兼容，InnoDB就将请求的锁授予该事务；反之，如果两者不兼容，该事务就要等待锁释放。
5、InnoDB行锁的实现方式
InnoDB的行锁实现是通过给索引上的索引项加锁来实现的；也就说只有通过索引检索数据，InnoDB才使用行级锁，否则InnoDB将使用表锁。
注意点：
a、在不通过索引条件查询的时候，InnoDB确实使用的是表锁，而不是行锁。
b、由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的。
c、当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁。
d、即便在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的，如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。
6、间隙锁
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）。
目的
InnoDB使用间隙锁的目的，一方面是为了防止幻读，以满足相关隔离级别的要求，如果不使用间隙锁，如果其他事务插入了超过范围的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；另外一方面，是为了满足其恢复和复制的需要。
很显然，在使用范围条件检索并锁定记录时，InnoDB这种加锁机制会阻塞符合条件范围内键值的并发插入，这往往会造成严重的锁等待。因此，在实际应用开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。
死锁
发生死锁后，InnoDB一般都能自动检测到，并使一个事务释放锁并回退，另一个事务获得锁，继续完成事务。但在涉及外部锁，或涉及表锁的情况下，InnoDB并不能完全自动检测到死锁，这需要通过设置锁等待超时参数 innodb_lock_wait_timeout来解决。需要说明的是，这个参数并不是只用来解决死锁问题，在并发访问比较高的情况下，如果大量事务因无法立即获得所需的锁而挂起，会占用大量计算机资源，造成严重性能问题，甚至拖跨数据库。我们通过设置合适的锁等待超时阈值，可以避免这种情况发生。
通常来说，死锁都是应用设计的问题，通过调整业务流程、数据库对象设计、事务大小，以及访问数据库的SQL语句，绝大部分死锁都可以避免。下面就通过实例来介绍几种避免死锁的常用方法。
1、在应用中，如果不同的程序会并发存取多个表，应尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会。
2、在程序以批量方式处理数据的时候，如果事先对数据排序，保证每个线程按固定的顺序来处理记录，也可以大大降低出现死锁的可能。
3、在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应先申请共享锁，更新时再申请排他锁，因为当用户申请排他锁时，其他事务可能又已经获得了相同记录的共享锁，从而造成锁冲突，甚至死锁。
4、在REPEATABLE-READ隔离级别下，如果两个线程同时对相同条件记录用SELECT...FOR UPDATE加排他锁，在没有符合该条件记录情况下，两个线程都会加锁成功。程序发现记录尚不存在，就试图插入一条新记录，如果两个线程都这么做，就会出现死锁。这种情况下，将隔离级别改成READ COMMITTED，就可避免问题
5、当隔离级别为READ COMMITTED时，如果两个线程都先执行SELECT...FOR UPDATE，判断是否存在符合条件的记录，如果没有，就插入记录。此时，只有一个线程能插入成功，另一个线程会出现锁等待，当第1个线程提交后，第2个线程会因主键重出错，但虽然这个线程出错了，却会获得一个排他锁！这时如果有第3个线程又来申请排他锁，也会出现死锁。