mysql 行锁 间隙锁 表锁
行锁
总结：多个事务操作同一行数据时，后来的事务处于阻塞等待状态。这样可以避免了脏读等数据一致性的问题。后来的事务可以操作其他行数据，解决了表锁高并发性能低的问题。
# Transaction-A
mysql> set autocommit = 0;
mysql> update innodb_lock set v='1001' where id=1;
mysql> commit;
# Transaction-B
mysql> update innodb_lock set v='2001' where id=2;
Query OK, 1 row affected (0.37 sec)
mysql> update innodb_lock set v='1002' where id=1;
Query OK, 1 row affected (37.51 sec)
复制代码现实：当执行批量修改数据脚本的时候，行锁升级为表锁。其他对订单的操作都处于等待中，，， 原因：nnoDB只有在通过索引条件检索数据时使用行级锁，否则使用表锁！ 而模拟操作正是通过id去作为检索条件，而id又是MySQL自动创建的唯一索引，所以才忽略了行锁变表锁的情况
总结：InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。并且该索引不能失效，否则都会从行锁升级为表锁。
- 行锁的劣势：开销大；加锁慢；会出现死锁
- 行锁的优势：锁的粒度小，发生锁冲突的概率低；处理并发的能力强
- 加锁的方式：自动加锁。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁；对于普通SELECT语句，InnoDB不会加任何锁；当然我们也可以显示的加锁：
从上面的案例看出，行锁变表锁似乎是一个坑，可MySQL没有这么无聊给你挖坑。这是因为MySQL有自己的执行计划。 当你需要更新一张较大表的大部分甚至全表的数据时。而你又傻乎乎地用索引作为检索条件。一不小心开启了行锁(没毛病啊！保证数据的一致性！)。可MySQL却认为大量对一张表使用行锁，会导致事务执行效率低，从而可能造成其他事务长时间锁等待和更多的锁冲突问题，性能严重下降。所以MySQL会将行锁升级为表锁，即实际上并没有使用索引。 我们仔细想想也能理解，既然整张表的大部分数据都要更新数据，在一行一行地加锁效率则更低。其实我们可以通过explain命令查看MySQL的执行计划，你会发现key为null。表明MySQL实际上并没有使用索引，行锁升级为表锁也和上面的结论一致。
注意：行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁。
间隙锁
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）。 举例来说，假如emp表中只有101条记录，其empid的值分别是 1,2,...,100,101，下面的SQL：
Select * from emp where empid > 100 for update;
复制代码是一个范围条件的检索，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的“间隙”加锁。
InnoDB使用间隙锁的目的，一方面是为了防止幻读，以满足相关隔离级别的要求，对于上面的例子，要是不使用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；另外一方面，是为了满足其恢复和复制的需要。有关其恢复和复制对锁机制的影响，以及不同隔离级别下InnoDB使用间隙锁的情况，在后续的章节中会做进一步介绍。
很显然，在使用范围条件检索并锁定记录时，InnoDB这种加锁机制会阻塞符合条件范围内键值的并发插入，这往往会造成严重的锁等待。因此，在实际应用开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。
还要特别说明的是，InnoDB除了通过范围条件加锁时使用间隙锁外，如果使用相等条件请求给一个不存在的记录加锁，InnoDB也会使用间隙锁！
例子：假如emp表中只有101条记录，其empid的值分别是1,2,......,100,101。
InnoDB存储引擎的间隙锁阻塞例子
| session_1 | session_2 |
|---|---|
| mysql> select @@tx_isolation; | mysql> select @@tx_isolation; |
| +-----------------+ | +-----------------+ |
| @@tx_isolation | @@tx_isolation |
| +-----------------+ | +-----------------+ |
| REPEATABLE-READ | REPEATABLE-READ |
| +-----------------+ | +-----------------+ |
| 1 row in set (0.00 sec) | 1 row in set (0.00 sec) |
| mysql> set autocommit = 0; | mysql> set autocommit = 0; |
| Query OK, 0 rows affected (0.00 sec) | Query OK, 0 rows affected (0.00 sec) |
| 当前session对不存在的记录加for update的锁： | |
| mysql> select * from emp where empid = 102 for update; | |
| Empty set (0.00 sec) | |
| 这时，如果其他session插入empid为201的记录（注意：这条记录并不存在），也会出现锁等待： | |
| mysql>insert into emp(empid,...) values(201,...); | |
| 阻塞等待 | |
| Session_1 执行rollback： | |
| mysql> rollback; | |
| Query OK, 0 rows affected (13.04 sec) | |
| 由于其他session_1回退后释放了Next-Key锁，当前session可以获得锁并成功插入记录： | |
| mysql>insert into emp(empid,...) values(201,...); | |
| Query OK, 1 row affected (13.35 sec) |
危害(坑)：若执行的条件是范围过大，则InnoDB会将整个范围内所有的索引键值全部锁定，很容易对性能造成影响。
表锁
如何加表锁？ innodb 的行锁是在有索引的情况下，没有索引的表是锁定全表的。
Innodb中的行锁与表锁
前面提到过，在Innodb引擎中既支持行锁也支持表锁，那么什么时候会锁住整张表，什么时候只锁住一行呢？ 只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！
在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。
行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁。行级锁的缺点是：由于需要请求大量的锁资源，所以速度慢，内存消耗大。
作者：蒋老湿
链接：https://juejin.im/post/5b82e0196fb9a019f47d1823
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。