文章目录
简介
- 当数据库有并发事务的时候，可能会产生数据的不一致，这时候需要一些机制来保证访问的次序，锁机制就是这样的一个机制。
1.MySQL锁的分类
1.1 按锁的粒度划分
- 分为：行锁、页锁、表锁
锁定的粒度越小，发生锁冲突的概率越低，可以实现的并发度越高 ；但是对于锁的开销比较大，加锁会比较慢，容易出现死锁。
1.1.1 行锁
-
行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。
-
行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。行级锁分为 共享锁 和 排他锁。
-
特点
开销大，加锁慢；
会出现死锁；
锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 -
行锁的三种类型
1、Record Lock 单个记录上的锁
对索引项加锁，如果innodb引擎的表在建立的时候 没有设置任何索引 那么这时候对InnoDB存储引擎会用隐性的主键来进行锁定。
2、Gap Lock 间隙锁
对索引项之间的间隙加锁，锁定一个范围，但不包含记录本身
设计目的： 为了解决幻读，利用这种锁技术，锁定的不是单个值，而是一个范围。
3、Next-key lock
则是前面两种的组合，对索引项以其之间的间隙加锁。Gap Lock + Record Lock，锁定一个范围，并且锁定记录本身
只有在可重复读或以上的隔离级别下的特定操作才会取得gap lock或者 next-key lock，在select update delete时，除了基于唯一索引的查询之外，其他索引都会获取gap lock 或者 next-key lock，即锁住扫描的范围。
1.1.2 页面锁
-
页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。
表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。 -
特点
开销和加锁时间界于表锁和行锁之间；
会出现死锁；
锁定粒度界于表锁和行锁之间，并发度一般 -
封锁粒度小：
好处：锁定的数据量越少，发生锁争用的可能就越小，系统的并发程度就越高；
坏处：系统开销大（加锁、释放锁、检查锁的状态都需要消耗资源）
1.1.3 表锁
-
表锁是MySQL中锁定粒度最大的一种锁，表示对当前操作的整张表加锁，它实现简单，资源消耗较少，被大部分MySQL引擎支持。最常使用的MYISAM与INNODB都支持表级锁定。
-
表级锁定分为表共享读锁（共享锁）与表独占写锁（排他锁）。
-
特点
开销小，加锁快；
不会出现死锁；
锁定粒度大，发生锁冲突的概率最高，并发度最低。
1.2 从数据库的管理角度区分
- 分为：共享锁和排他锁 ，即读锁和写锁–》MySQL常见的锁类型
1.2.1 共享锁/S锁
- 也叫读锁或者S锁
共享锁的资源可以被其他用户读取，但是不能修改；
在select时，会将对象进行共享锁锁定；
读取完毕时，就会释放锁，就可以保证数据在读取时不会被修改。
mysql> lock table xxx read;
mysql> unlock table;
-
场景：相当于对于同一把门，它拥有多个钥匙一样。
-
在执行语句后面加上lock in share mode就代表对某些资源加上共享锁了。
mysql> SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE; #共享锁
- 共享锁出现死锁的原因：多个事务对同一数据获得读锁的时候，可能会出现死锁。
1.2.2 排他锁/X锁
- 也叫独占锁，写锁或者X锁。
排它锁，锁定的数据只允许进行锁定的事务使用；
其他事务无法对已锁定的数据进行查询和操作。
mysql> lock table xxx write;
mysql> unlock table;
- 事务对数据加上X锁时，只允许此事务读取和修改此数据，并且其它事务不能对该数据加任何锁；
SELECT * FROM table_name WHERE ... FOR UPDATE； # 排它锁
1.3 从程序员的角度区分
- 可以将锁划分为乐观锁和悲观锁。
1.3.1 乐观锁
-
乐观锁认为对同一数据的并发操作不会总发生，持乐观态度，属于小概率事件；不需要每次都对数据上锁，也就是不采用数据库自身的锁机制，而是通过程序来实现；
-
在程序上，我们可以采用版本号机制或者时间戳机制来实现； 其实就是程序层面控制，不会存在死锁的问题，但是阻止不了程序之外的数据库操作。
-
主要的实现方式：
1、版本号机制：
新增version字段,第一次读取的时候会获取version的值，然后对数据进行更新和删除操作时，会进行版本号的比对；
如果版本号一致，则修改数据，并将版本号+1；如果版本号不一致 则修改失败。
2、时间戳机制：
其道理和版本号一样。
1.3.2 悲观锁
- 实际上是一种思想，对数据被其他的事务修改持保守态度 会通过数据库自身的锁机制来实现，保证数据操作的排他性!
- 对数据冲突持有悲观的态度，则认为肯定会冲突，那么在每次数据读取的时候将数据锁住；之后所有的操作读取操作都需要等待；
- 数据库层面实现，阻止一切数据库操作。
2.常见的死锁问题
-
必要条件：互斥，占有且等待，不可强占用，循环等待。
-
解决死锁的方法：
最佳方式就是防止死锁的发生。
注意的一些细节：
1、不要将无关的操作放进事务里，小事务发生死锁的概率很低；
2、如果不同的程序会同时操作多个表，应尽量约定以相同的顺序来访问表，这样事务就会形成良好的定义的查询；
3、尽量按照索引去查数据，范围查找增加了锁的可能性；
4、对于非常容易产生死锁的业务部分，可以尝试升级锁的粒度；
5、更新表时，尽量使用主键更新；
6、设置锁等待超时参数，通过设置 innodblockwait_timeout 参数，设置合理的等待阈值；在高并发的业务中，尽量
将该值设置的小一点，避免大量事务等待，占用系统资源，造成严重的性能开销；
7、Innodb提供了wait-for graph算法来主动进行死锁检测，我们可以通过innodbdeadlockdetect = on 打开死锁检测。