MySQL--6锁机制

1. mysql锁基础

知识点范围:

锁等待现象
表级锁：锁住一张表的数据 =》 myisam ，innodb
页级锁：是锁一页的数据
行级锁：锁住一行的数据 =》 innodb

1.1

• InnoDB 存储引擎既支持行级锁，也支持表级锁，默认情况下使用行级锁。
• 所谓表级锁，它直接锁住的是一个表，开销小，加锁快，不会出现死锁的情况，锁定粒度大，发生锁，冲突的概率更高，并发度最低。
• 所谓行级锁，它直接锁住的是一条记录，开销大，加锁慢，发生锁冲突的概率较低，并发度很高。
• 所谓页级锁，它是锁住的一个页面，在 InnoDB 中一个页面为16KB，它的开销介于表级锁和行级锁中间，也可能会出现死锁，锁定粒度也介于表级锁和行级 锁中间，并发度也介于表级锁和行级锁中间。

仅仅从锁的角度来说，表级锁更加适合于以查询为主的应用，只有少量按照索引条件更新数据的应用，比如大多数的 web 应用。
行级锁更适合大量按照索引条件并发更新少量不同的数据，同时还有并发查询的应用，比如一些在线事务处理系统，即 OLTP。

下面介绍innodb引擎的锁

innodb锁

1.InnoDB 与 MyISAM 的相当大的两点不同在于: (1) 支持事务 (2) 采用行级锁
2.行级锁本身与表级锁的实现差别就很大，而事务的引入也带来了很多新问题，尤其是事务的隔离性，与锁机制息息相关。
3.对于事务的基本操作，对于不同隔离级别可能引发的问题，像脏读、不可重复读等问题。
4.数据库实现事务隔离的方式，基本可以分为两种:

(1) 在操纵数据之前，先对其加锁，防止其他事务对数据进行修改。这就需要各个事务串行操作才 可以实现。
(2) 不加任何锁，通过生成一系列特定请求时间点的一致性数据快照，并通过这个快照来提供一致 性读取。

5.上面的第二种方式就是数据多版本并发控制，也就是多版本数据库，一般简称为 MVCC 或者 MCC，它是 Multi Version Concurrency Control 的简写。
6.数据库的事务隔离越严格，并发的副作用就越小，当然付出的代价也就越大，因为事务隔离机制实质上是使得事务在一定程度上”串行化”,这与并行是矛盾 的。

innodb锁的类型

1.InnoDB 实现了下面两种类型的锁:

• (1)共享锁(S):允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
• (2)排他锁(X):允许获得排他锁的事务更新数据，阻止其他事务获得相同数据集的共享读锁和排他写 锁。
• 这里有个锁兼容和冲突的概念，如果在加一个锁的时候，另一个锁可以加上去，那么就是锁兼容。如 果加上一个锁之后，拒绝其他的锁加上，那么就是锁冲 突。
• 我们可以使用如下语句来显式的给数据集加锁:

(1)共享锁(S):select * from t1 where ... lock in share mode; (2)排他锁(X):select * from t1 where ... for update;

• 我们可以用 select ...in share mode 来获得共享锁，主要用在数据依存关系时来确认某行记录是否存 在，并确认没有人对这个记录进行 update 或者 delete 操 作。
• 我们可以使用 select... for update 来获得排他锁，它会拒绝其他事务在其上加其他锁。

注解：排它锁加锁语法:

--给`user`表id为1的数据加排它锁
start transaction--开启事务
select * from `user` where id=1 for update;--给id为1的数据加排它锁 
commit;--提交事务
rollback;--回滚事务

注解：共享锁加锁语法:

start transaction--开启事务
select * from `user` where id=1 lock in share mode;--给id为1的数据加共享锁
commit;--提交事务
rollback;--回滚事务

（重点）注解：当事务给一行数据加共享锁，那么其他事务可以加共享锁，但不能加排它锁。

即:能读不能写，可以与共享锁一起使用，但不能与排它锁一起使用;

小结：个人理解解释
1.1 排它锁：数据在用的时候，排它锁是不能被查询到的，只能上一个查询完毕，提交完事物，才能进行查询下一个。排它锁跟共享锁不能一起使用。
1.2 共享锁：可以进行多个用户共享数据，排它锁跟共享锁也不能一起使用。
begin 会自动开启事物
对于update，insert，alter等写操作，MySQL会自动加上排它锁。
当前读取：一般指的是加锁的select
快照读取：一般指的是没加锁的普通查询

下面我们来解释另外锁：乐观锁与悲观锁的解释。

悲观锁：悲观锁，不管是什么锁，只要是上了锁都属于悲观锁。
乐观锁：共享锁就是乐观锁—MVCC
悲观锁，乐观锁：是一个概念，是一种思想。因为只要是排它锁，跟共享锁，就叫悲观，跟乐观锁。

在来看MySQL的死锁

1.死锁怎么产生的：

• 所谓死锁:是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作 用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为 死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。
• 死锁的关键在于:两个(或以上)的Session加锁的顺序不一致。 那么对应的解决死锁问题的关键就是:让不同的session加锁有次序。

个人理解
1.1 死锁现象：在锁等待的时候，我们称为：死锁
死锁：一般是在事物1在执行，事物2在等待。
锁等待的时间是：wait timeout =120 设置的是锁等待时间，锁等待时间结束之后有一个失败，一个成功。
mysql的选择与事物的大小有关系，soloct舍小保大。
模糊查询的查询，范围查询，会导致死锁。
说明了事物与事物产生的死锁

2.尽可能的避免事务死锁

• 1)以固定的顺序访问表和行。比如对第2节两个job批量更新的情形，简单方法是对id列表先排序，后执 行，这样就避免了交叉等待锁的情形;又比如对于3.1节的情形，将两个事务的sql顺序调整为一致，也能避 免死锁。
• 2)大事务拆小。大事务更倾向于死锁，如果业务允许，将大事务拆小。
• 3)在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁概率。
• 4)降低隔离级别（默认事物隔离级别）。如果业务允许，将隔离级别调低也是较好的选择，比如将隔离级别从RR调整为RC，可以避免掉很多因为gap锁造成的死锁。
• 5)为表添加合理的索引。可以看到如果不走索引将会为表的每一行记录添加上锁，死锁的概率大大增大。

间隙锁与行锁升级为表锁

1.1 间隙锁：当我们使用范围查询，而不是等式查询，并请求或者排它锁的时候
间隙锁的危害会产生死锁：如果在查询中通过范围去查询，锁锁住的范围会是所有索引的键值。即使这个数据不存在

什么情况下行锁升级成表锁

1.1 锁去锁住数据=》是与索引有一点的关联
1.2 主键与唯一索引几乎为0
1.3 普通索引：很大几率会数据出现重复。
1.4：在不加索引的字段（除主键以及唯一索引之外）上进行数据的加锁，会升级为表锁。
在加了索引之后加锁会根据普通索引的基础上去进行加锁。
而一旦索引失效，有会升级会表锁。

1. 会尽可能是索引字段进行加锁
2. 尽可能使用等式而不是范围性的查询。
   不只是排它锁，共享锁也是一样的道理