数据库-锁机制-通俗易懂介绍
一、为什么需要使用锁，什么是锁
官方的介绍：
锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统计算资源（CPU、RAM、I\O等）的争抢，数据也是一种供多用户共享的资源。如何保证数据并发访问的一致性，有效性，是所有数据库必须要解决的问题。锁冲突也是影响数据库并发访问性能的一个重要因素，因此锁对数据库尤其重要。
对于上面的几句话介绍什么是锁，相信看了后抽象难以理解，下面我举一个生活中通俗易懂的例子，说明什么是锁，以及为什么需要使用锁。
【工人搬转的例子】
- 一个工人搬砖时
假如现在一个老板有堆砖头一共有30块左右，需要找人帮忙。随后就找到了A工人搬转。
- 多个工人搬砖时
然后，老板又觉得一个人搬砖太慢了，所以就多叫两个工人，B工人、C工人过来帮忙。
- 多个工人搬砖时，会带来的问题
1、会发现工人们之间，说的砖头数量不一样
假如三个ABC工人同一时间去搬砖的。大家一开始只知道那堆砖头有30块而已。
比如工人去搬5块砖头，心里想搬完5块，还有25块。
接着B工人去搬6块砖头。心里想搬完5块，还有24块。
接着C工人去搬1块砖头。心里想搬完1块，还有29块。
最后老板过来问大家，现在还多少砖头。A工人：25块、B工人：24块、C工人：29块。
一听，这数量不对呀，各说各的，肯定有问题这样。其实真实还有30-12=18块而已，但是工人之间都不知道，大家搬了多少块砖头。
- 解决多个工人搬砖时，带来的问题
为了解决上述的问题，老板就想了个办法。
A搬砖时，B、C工人不能去搬砖，只有A工人搬完离开，B、C工人才可以去搬砖头。
并且告诉B工人现在还有多少块砖头，B工人和C工人同理。
好了，举完这个🌰我们就可以来看关于 锁 的一些基础概念了，你会发现这东西理解起来怎么这么简单。👊👊👊
并发访问：其实相当于多个工人，去搬砖。
同一资源：就是工人搬砖中的那堆30块砖头。
锁机制（同步机制）：这里就有点类似，那堆砖头四周有铁网围住，有个铁网门可以进入，A工人去那一把锁，进入里面后，立刻把铁网门锁住。不让BC工人进来，只有当A打开锁后出来。BC工人才可以进入。
二、锁有哪些
1、按数据操作的粒度来分
表锁
行锁
页锁
2、按数据操作的类型来分
读锁（共享锁、S锁）
写锁（排他锁或互斥锁、X锁）
3、按使用方式来分
乐观锁
悲观锁
分析下表、行、页锁的读写情况：
表锁下的读写操作时：
表锁的特点：
表锁对整张表加锁，开销小，加锁快，无死锁，锁粒度大，发生锁冲突概率大，并发性低。是MyISAM的默认锁级别。
而读锁会阻塞写操作，不会阻塞读操作。写锁会阻塞读操作写操作。MyISAM的读写锁调度是写优先，这也是MyISAM不适合做写为主表的引擎，因为写锁以后，其它线程不能做任何操作，大量的更新使查询很难得到锁，从而造成永远阻塞。
读锁（read lock）
也叫共享锁（shared lock）、S锁，针对同一份数据，多个读操作可以同时进行而不会互相影响（select）。
写锁（write lock）
也叫排他锁（exclusive lock）、X锁，当前操作没完成之前，会阻塞其它读和写操作（update、insert、delete）。
如何上锁：
隐式上锁（默认，自动加锁自动释放）
select // 上读锁
insert、update、delete // 上写锁
显式上锁（手动）
lock table tableName read; // 读锁
lock table tableName write; // 写锁
解锁（手动）
unlock tables; // 所有锁表
行锁下的读写操作时：
行锁的特点
行锁对一行数据加锁，开销大，加锁慢，会出现死锁。行锁的锁粒度小，发生锁冲突概率最低，并发性高。
读锁（read lock）
也叫共享锁（shared lock），允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
写锁（write lock）
也叫排他锁（exclusive lock），允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享锁和排他锁。
意向共享锁（IS）
一个事务给一个数据行加共享锁时，必须先获得表的IS锁。
意向排它锁（IX）
一个事务给一个数据行加排他锁时，必须先获得该表的IX锁。
如何上锁
隐式上锁（默认，自动加锁自动释放）
select // 不会上锁
insert、update、delete // 上写锁
显式上锁（手动）
select * from tableName lock in share mode; // 读锁
select * from tableName for update; // 写锁
解锁（手动）
1. 提交事务（commit）
2. 回滚事务（rollback）
3. kill 阻塞进程
因为InnoDB有MVCC机制（多版本并发控制），可以使用快照读，而不会被阻塞，所以上了写锁，别的事务还可以读操作。
页锁
开销、加锁时间和锁粒度介于表锁和行锁之间，会出现死锁，并发处理能力一般。
三、乐观锁和悲观锁
锁从使用方式来分可分为乐观锁和悲观锁，乐观锁和悲观锁在很多应用当中都存在的概念，并不是实质存在的锁叫乐观锁悲观锁，在mysql数据中有，在hibernate、java等当中也有。
-
乐观锁是在遇到事物并发问题时，想法很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，认为这次的操作不会导致冲突，当出现事物并发问题时再处理。乐观锁由于加锁少，所以性能开销比较小，吞吐量大。
-
悲观锁的特点是先获取锁，再进行业务操作。每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，开始就默认会出现事物并发问题，所以在进行每次操作数据时都要通过获取锁才能进行对相同数据的操作，悲观锁需要耗费较多的时间，处理并发问题也相对严谨，在核心业务的关键之处可使用悲观锁，开销相对来说大。
举个例子：
经典高并发 ，如何避免库存超发问题，平时在购买商品操作库存流程大概如下：
假如当前库存量为5，第一个购买请求数量为4个，顺利购买，当前剩余1，第二次购买4个，此时库存不足，程序直接返回库存不足，购买失败。
上述情况不是在高并发情况下，在高并发情况下，可能有多个请求同时购买，同时读取库存更新存库，两次请求同时读取到的库存都是5，然后都执行购买操作，减库存，就出现了库存超发现象，库存减至-3。
类似问题可以用乐观锁、悲观锁来解决。
1、悲观锁解决方案
出现超发的问题根本原因就是共享的数据被多个线程同时修改，如果单独的一个线程想要修改数据，在读取数据时将数据锁定，加排他锁，不允许其他线程读取和修改数据，直到存库修改完成释放锁，就不会出现超发现象。
//开始事物
select id,productid,stock from zproduct where id=? for update;
update zproduct set stock=stock-? where id=?;
//结束事物
使用for update给行数据加排他锁，其他事物就不能对它读和写，避免了数据同时被多个事物修改，此解决方案是实现比较简单，缺点是加排他锁影响系统的并发性能。
2、乐观锁解决方案
悲观锁很容易产生线程阻塞，为了提高性能，出现了乐观锁方案，不使用数据库锁，不阻塞线程并发。
实现方法：给商品添加一个version字段，代码行修改版本号，读取库存是拿到这个version版本号，在更新时再对比version版本号，如果版本号相同，说明库存没有被其他线程修改过，可以正常操作，同时把version数值加1。如果版本号不同，代表被别的线程修改过，则取消修改库存操作，返回购买失败。
update zproduct set stock=stock-?,version=version+1 where id=? and version=?;
为进一步完善，可以借鉴中间件的重试机制，更新失败后，重新来一遍，重新读取、修改，超过一定时间一定重试次数后，还不成功就放弃，返回失败，否则成功。
四、行锁的实现算法
1、Record Lock 锁
单个行记录上的锁Record Lock总是会去锁住索引记录，如果InnoDB存储引擎表建立的时候没有设置任何一个索引，这时InnoDB存储引擎会使用隐式的主键来进行锁定。
2、Gap Lock 锁
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引加锁，对于键值在条件范围内但并不存在的记录。优点是解决了事务并发的幻读问题，不足是因为query执行过程中通过范围查找的话，他会锁定整个范围内所有的索引键值，即使这个键值并不存在。间隙锁有一个致命的弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被无辜的锁定，而造成锁定的时候无法插入锁定键值范围内任何数据。在某些场景下这可能会对性能造成很大的危害。
3、Next-key Lock 锁
同时锁住数据+间隙锁在Repeatable Read隔离级别下，Next-key Lock 算法是默认的行记录锁定算法。
只有通过索引条件检索数据时，InnoDB才会使用行级锁，否则会使用表级锁（索引失效，行锁变表锁），即使是访问不同行的记录，如果使用的是相同的索引键，会发生锁冲突，如果数据表建有多个索引时，可以通过不同的索引锁定不同的行。
五、死锁
死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。
产生的条件是：
- 互斥条件：一个资源每次只能被一个进程使用。
- 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
- 不剥夺条件：进程已获得的资源，在没有使用完之前，不能强行剥夺。
- 循环等待条件：多个进程之间形成的一种互相循环等待的资源的关系。
解决办法是：
- 查看死锁：show engine innodb status \G。
- 自动检测机制，超时自动回滚代价较小的事务（innodb_lock_wait_timeout 默认50s）。
- 人为解决，kill阻塞进程（show processlist）。
- wait for graph 等待图（主动检测）。
可以通过以下方式避免：
- 加锁顺序一致，尽可能一次性锁定所需的数据行。
- 尽量基于primary（主键）或unique key更新数据。
- 单次操作数据量不宜过多，涉及表尽量少。
- 减少表上索引，减少锁定资源。
- 尽量使用较低的隔离级别。
- 尽量使用相同条件访问数据，这样可以避免间隙锁对并发的插入影响。
- 精心设计索引，尽量使用索引访问数据。
- 借助相关工具：pt-deadlock-logger。
参考：
https://blog.csdn.net/a281246240/article/details/86507118
https://zhuanlan.zhihu.com/p/446451109
https://blog.csdn.net/cmm0401/article/details/107299458
https://juejin.cn/post/6844903668571963406#heading-1
https://developer.aliyun.com/article/741811?utm_content=g_1000098827&from=timeline&isappinstalled=0
