MySQL的锁

https://www.cnblogs.com/volcano-liu/p/9890832.html

MySQL的锁按照粒度分为：

1. 表级锁
2. 行级锁
3. 页级锁（不常用）

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低；
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高；

对于MyISAM引擎

使用表级锁的锁模式。

MySQL的表级锁有两种模式：

1. 表共享读锁（Table Read Lock）
2. 表独占写锁（Table Write Lock）。

锁模式的兼容性：

1. 对MyISAM表的读操作，不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求；
2. 对MyISAM表的写操作，则会阻塞其他用户对同一表的读和写操作；
3. MyISAM表的读操作与写操作之间，以及写操作之间是串行的。当一个线程获得对一个表的写锁后，只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待，直到锁被释放为止。

对于InnoDB引擎

InnoDB行锁实现方式

InnoDB行锁是通过给索引上的索引项加锁来实现的，**只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁。**在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。下面通过一些实际例子来加以说明。

1. 在不通过索引条件查询的时候，InnoDB确实使用的是表锁，而不是行锁。
2. 由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的。
3. 当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁。

InnoDB共有七种类型的锁：

1. 共享/排它锁(Shared and Exclusive Locks)
2. 意向锁(Intention Locks)
3. 记录锁(Record Locks)
4. 间隙锁(Gap Locks)
5. 临键锁(Next-key Locks)
6. 插入意向锁(Insert Intention Locks)
7. 自增锁(Auto-inc Locks)

共享/排它锁(Shared and Exclusive Locks)

行级锁也有共享锁和排它锁。

共享锁（Share Locks，记为S锁），读取数据时加S锁
排他锁（eXclusive Locks，记为X锁），修改数据时加X锁

使用的语义为：
共享锁之间不互斥，简记为：读读可以并行
排他锁与任何锁互斥，简记为：写读，写写不可以并行

可以看到，一旦写数据的任务没有完成，数据是不能被其他任务读取的，这对并发度有较大的影响。对应到数据库，可以理解为，写事务没有提交，读相关数据的select也会被阻塞，这里的select是指加了锁的，普通的select仍然可以读到数据(快照读)。

意向锁(Intention Locks)

意向锁是InnoDB自动加的，不需用户干预。

锁定机制的实现过程中为了让行级锁定和表级锁定共存，InnoDB也同样使用了意向锁（表级锁定）的概念，也就有了意向共享锁和意向排他锁这两种。

如果遇到自己需要锁定的资源已经被一个排他锁占有之后，则只能等待该锁定释放资源之后自己才能获取锁定资源并添加自己的锁定。而意向锁的作用就是当一个事务在需要获取资源锁定的时候，如果遇到自己需要的资源已经被排他锁占用的时候，该事务可以需要锁定行的表上面添加一个合适的意向锁。

如果自己需要一个共享锁，那么就在表上面添加一个意向共享锁。而如果自己需要的是某行（或者某些行）上面添加一个排他锁的话，则先在表上面添加一个意向排他锁。意向共享锁可以同时并存多个，但是意向排他锁同时只能有一个存在。

间隙锁（Next-Key锁）

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；
对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）。

例：
假如emp表中只有101条记录，其empid的值分别是 1,2,…,100,101，下面的SQL：

mysql> select * from emp where empid > 100 for update;

是一个范围条件的检索，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的“间隙”加锁。
InnoDB使用间隙锁的目的：

1. 防止幻读，以满足相关隔离级别的要求。对于上面的例子，要是不使用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；
2. 为了满足其恢复和复制的需要。

innodb自动使用间隙锁的条件：

1. 必须在RR级别（可重复读）下
2. 检索条件必须有索引（没有索引的话，mysql会全表扫描，那样会锁定整张表所有的记录，包括不存在的记录，此时其他事务不能修改不能删除不能添加）

为什么我们通常用RC（读已提交）而不用RR（可重复读）？

1. 在RR隔离级别下，存在间隙锁，导致出现死锁的几率比RC大的多！
2. 在RR隔离级别下，条件列未命中索引会锁表！而在RC隔离级别下，只锁行。
3. 在RC隔离级别下，半一致性读(semi-consistent)特性增加了update操作的并发性！

防止死锁的方式：

1. 在应用中，如果不同的程序会并发存取多个表，应尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会。
2. 在程序以批量方式处理数据的时候，如果事先对数据排序，保证每个线程按固定的顺序来处理记录，也可以大大降低出现死锁的可能。
3. 在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应先申请共享锁，更新时再申请排他锁，因为当用户申请排他锁时，其他事务可能又已经获得了相同记录的共享锁，从而造成锁冲突，甚至死锁。

https://www.cnblogs.com/luyucheng/p/6297752.html