MySQL的锁机制，就是数据库为了保证数据的一致性而设计的面对并发场景的一种规则。

　　最显著的特点是不同的存储引擎支持不同的锁机制，InnoDB支持行锁和表锁，MyISAM支持表锁。

　　表锁就是把整张表锁起来，特点是加锁快，开销小，不会出现死锁，锁粒度大，发生锁冲突的概率高，并发相对较低。
　　行锁就是以行为单位把数据锁起来，特点是加锁慢，开销大，会出现死锁，锁粒度小，发生锁冲突的概率低，并发度也相对表锁较高。

　　在MyISAM引擎中，读锁和写锁是互斥的，读写操作是串行的，锁设计方案如下：

　　对于写操作：如果表上没有锁，则在上面加一把写锁，否则，把请求放到写锁队列中。
　　对于读操作：如果表上没有锁，则在上面加一把读锁，否则，把请求方到读锁队列中。

　　这是什么意思呢？

　　意思就是说MyISAM在执行查询语句前，会自动给涉及的所有表加读锁，在执行更新语句(增删改操作)前，会自动给涉及的表加写锁，这个过程并不需要用户干预。

　　当一个锁被释放时，锁定权会先被写锁队列中的线程得到，当写锁队列中的请求都跑完后，才轮到读锁队列中的请求。（即使读请求先到锁等待队列中，写请求后到，写请求也会插入到读请求之前！这就是MySQL认为写请求一般比读请求重要）

　　这就意味着，如果一个表上有很多更新操作，那么select语句将等待直到别的更新都结束后才能查到东西。这也就是为什么MyISAM表不适合大量更新操作应用的原因，因为大量更新操作可能导致查询操作很难获得读锁，从而长久阻塞，致使程序响应超时。

　　表锁语句有如下三条（MyISAM和InnoDB都一样）：

　　LOCK TABLES tb_name READ; 加读锁，其他会话可读，但不能更新。
　　LOCK TABLES tb_name WRITE; 加写错，其他会话不可读，不可写。
　　UNLOCK TABLES; 释放锁

当有连续多表更新的时候，可能会出现频繁的表锁竞争，更新数据的速度反而会下降，并且更新这个表的时候另一个表的数据可能被别的线程更新了（MyISAM是没有事务的），这个时候，我们就需要锁住多张表，再进行更新。

这里示例，同时上锁更新两个表，给id为1的用户余额加1：

　　LOCK TABLES tb_1 WRITE,tb_2 WRITE;
　　UPDATE tb_1 SET balance=balance+1 WHERE user_id=1;
　　UPDATE tb_2 SET balance=balance+1 WHERE user_id=1;
　　UNLOCK TABLES;

特别注意：显式加锁的时候，必须同时取得所有涉及表的锁，并且，只能访问显式加锁的这些表，不能访问未加锁的表。

（MyISAM的内容就这一章，接下来的章节都是InnDB的了，特此说明哈。）

　　SELECT * FROM tb_name LOCK IN SHARE MODE;

　　一个事务获取了一个数据行的读锁，允许其他事务也来获取读锁，但是不允许其他事务来获取写锁。也就是说，我上了读锁之后，其他事务也可以来读，但是不能增删改。

　　SELECT * FROM tb_name FOR UPDATE;

　　一个事务获取了一个数据行的写锁，其他事务就不能再跑来获取任何锁了，所有请求都会被阻塞，直到当前的写锁被释放。

　　意向共享锁（IS）：事务在给一个数据行加共享锁之前必须先取得该表的IS锁。
　　意向排他锁（IX）：事务在给一个数据行加共享锁之前必须先取得该表的IX锁。
　　MDL锁：在事务中，InnoDB会给涉及的所有表加上一个MDL锁，其他事务就不可以执行任何DDL语句的操作。（亲测只要在事务中，不管是查询语句还是更新语句，涉及到的表都会被加上MDL锁）

　　这三种锁，是InnoDB内部使用的锁，是自动实现的，不需要用户干预。

　　这是一个索引记录锁，它是建立在索引记录上的锁（主键和唯一索引都算），很多时候，锁定一条数据，由于无索引，往往会导致整个表被锁住，建立合适的索引可以防止扫描整个表。

　　如：开两个会话，两个事务，并且都不commit，该表有主键，两个会话修改同一条数据，第一个会话update执行后，第二个会话的update是无法执行成功的，会进入等待状态，但是如果update别的数据行就可以成功。

　　再例如：开两个会话，两个事务，并且都不commit，并且该表无主键无索引，那么第二个会话不管改什么都会进入等待状态。因为无索引的话，整个表的数据都被第一个会话锁定了。

　　MySQL默认隔离级别是可重复读，这个隔离级别为了避免幻读现象，引入了这个间隙锁，对索引项之间的间隙上锁。

　　示例：

　　(会话1)
　　START TRANSACTION;
　　SELECT * FROM tb_name WHERE id>10 LOCK IN SHARE MODE;
　　（会话2）
　　START TRANSACTION;
　　INSERT INTO tb_name(id,name) VLUES(11,"张三")

　　结果怎样？会话2会进入执行等待状态，直至会话1的锁释放或者锁超时。

　　当InnoDB扫描索引记录时，会先对选中的索引记录加上记录锁（record Lock），再对索引记录两遍的间隙加上间隙锁（gap lock）。

　　还是以间隙锁的例子说，假如表中没有id=10的这行数据，会话2添加的id该为10，会成功吗？

　　答案是不会，因为它不止锁了id>10的间隙，连id=10也一起锁了。

　　在InnoDB中绝大部分都应该使用行锁，因为事务和行锁往往是我们选择InnoDB表的理由，但是在个别特殊事务中，也可以考虑使用表锁。

　　情况1：事务需要更新大部分或者全部数据，表又比较大，如果使用默认的行锁，不仅这个事务执行效率低，而且可能造成其他事务长时间锁等待和锁冲突，这种情况下可以考虑使用表锁来提高事务的执行速度。

　　情况2：事务涉及多个表，比较复杂，很可能引起死锁，造成大量事务回滚，这种情况也可以考虑一次性锁定事务涉及的表，从而避免死锁，减少数据库因事务回滚带来的开销。

　　当然，这两种情况不能太多，否则就应该从业务和程序设计上进行拆分处理，而不是由数据库来承担这个事情。

　　例子如下：

注意：在事务中锁表时，在事务结束前不要释放锁，因为unlock tables会隐含提交事务，所以正确的做法是结束事务后再释放锁。

　　锁等待是指一个事务过程中产生的锁，其他事务需要等待上一个事务释放它的锁，才能占用该资源，如果该事务一直不释放，就需要继续等待下去，直到超过了锁等待时间，会报一个超时错误。

　　查看锁等待允许时间：

　　死锁是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，就是所谓的死循环。

　　典型的实验过程就是两个事务并发，互相修改自己的一条数据，紧接着又修改对方的锁定的那条数据，都要等待对方的锁，死锁就产生了。

　　出现死锁的问题并不可怕，解决死锁通常有如下办法：

　　1.不要把无关的操作放到事务里，小事务发生冲突的概率较低。
　　2.如果不同的程序会并发存取多个表，应尽量约定以相同的顺序来访问表，这样事务就会形成定义良好的查询并且没有死锁。
　　3.尽量按照索引去查数据，范围查找增加了锁冲突的可能性。
　　4.对于非常容易产生死锁的业务部分，可以尝试升级锁粒度，通过表锁定来减少死锁产生的概率。

　　获取表锁争用情况：

    SHOW STATUS LIKE "table%"

　　查了很多资料，确实是这个获取方法，但是我自己没测出来它的用处，试了两台数据库都不行，很奇怪。

　　查询哪些表正在被锁定：