分类：
1.从数据操作类型分类：读锁、写锁：
读锁：也称共享锁。或S锁 针对同一份数据，多个事务的读操作可以同时进行而不会互相影响也不会互相阻塞写锁：也称排他锁。或X锁 当前写操作没完成前，会阻断其他写锁和读锁，确保给定的时间中，只有一个事务可以执行
注意：对于InnoDB来说，读锁和写锁可以加在表上，也可以加在行上，MyISAM不能加在行上
2.从数据操作的粒度划分：表级锁，页级锁，行锁
为了尽可能的提高数据库的并发度，每次锁定的数据的范围越小越好，理论上每次只锁定当前操作的数据的方案会得到最大的并发度，但是管理锁很耗费资源，因此数据库系统需要在高并发响应和系统性能两个方面进行平衡，这就是锁粒度的概念
表锁：
锁定整张表，是MySQL最基本的锁策略，可以避免死锁，但是并发量大大降低
① 表级别的S锁和X锁（不建议在InnoDB中使用）
② 意向锁：不需要显示的添加
InnoDB支持多粒度锁，允许行级锁和表级锁共存
1.意向锁的存在是为了协调行锁和表锁的关系，支持多粒度（表锁和行锁）的锁共存
2.意向锁是一种不与行级锁冲突的表级锁
3.表明某个事务正在某些行持有了锁或者该事务准备去持有锁
意向锁分为两种：
1.意向共享锁：事务有意对表中的某些行加共享锁2.意向排他锁：事务有意对表中的某些行加排他锁
意向锁需要解决的问题：
如果我们给某一行数据加了排他锁，数据库会自动给更大一级的空间，比如数据页或数据表加上意向锁，告诉其他人这个数据页或数据表已经有人上过排他锁了
③ 自增锁（保证主键唯一性）
④ 元数据锁（MDL锁）：不需要显示的添加
当对一个表做增删改查操作的时候，加MDL读锁，当要对表结构变更操作的时候，加MDL写锁
InnoDB中行锁：只在存储引擎层实现
优点：锁的力度小，发生锁冲突的概率低，可以实现高并发
缺点：对于锁的开销比较大，加锁会比较慢，容易出现死锁
InnoDB与MyISAM最大的区别：一是支持事务，二是支持行级锁
① 记录锁：仅仅把一条记录锁上（同样有S和X两种锁）
② 间隙锁（gap锁）：仅仅为了方式插入幻影记录，出现幻读，在某个区间范围加锁
间隙锁可能会导致死锁
两个事务锁定了统一个范围，就会导致均不能对该范围进行操作
③ 临键锁：相当于前两种锁的合体，相当于给间隙锁加上一个闭区间
④ 插入意向锁：
一个事务在插入一条记录的时候需要判断一下插入的位置是否被别的事务加了gap锁，若有则需要等待，直到那一个事务进行提交,但是InnoDB规定事务在等待的时候页需要在内存中生成一个锁结构，就是插入意向锁
插入意向锁是一种gap锁，并不是意向锁，在insert操作时产生
页锁：
页锁的开销介于表锁和行锁之间，也会出现死锁，并发度一般
3.从对待锁的态度分类：乐观锁和悲观锁（两种设计思想，并不是具体实现）
悲观锁是一种思想，顾名思义，就是很悲观，对数据被其他事务的修改持保守态度，会通过数据库自身
的锁机制来实现，从而保证数据操作的排它性。
悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上
锁，这样别人想拿这个数据就会 阻塞 直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，
用完后再把资源转让给其它线程）。比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，当
其他线程想要访问数据时，都需要阻塞挂起。Java中 synchronized 和 ReentrantLock 等独占锁就是
悲观锁思想的实现。
乐观锁认为对同一数据的并发操作不会总发生，属于小概率事件，不用每次都对数据上锁，但是在更新
的时候会判断一下在此期间别人有没有去更新这个数据，也就是不采用数据库自身的锁机制，而是通过
程序来实现。在程序上，我们可以采用 版本号机制 或者 CAS机制 实现。乐观锁适用于多读的应用类型，
这样可以提高吞吐量。在Java中 java.util.concurrent.atomic 包下的原子变量类就是使用了乐观锁
begin;
select * from student where id <=8 and id > 3 for update;
的一种实现方式：CAS实现的。
乐观锁的版本号机制
在表中设计一个 版本字段 version ，第一次读的时候，会获取 version 字段的取值。然后对数据进行更
新或删除操作时，会执行 UPDATE … SET version=version+1 WHERE version=version 。此时
如果已经有事务对这条数据进行了更改，修改就不会成功。
乐观锁的时间戳机制
时间戳和版本号机制一样，也是在更新提交的时候，将当前数据的时间戳和更新之前取得的时间戳进行
比较，如果两者一致则更新成功，否则就是版本冲突。
你能看到乐观锁就是程序员自己控制数据并发操作的权限，基本是通过给数据行增加一个戳（版本号或
者时间戳），从而证明当前拿到的数据是否最新。
从这两种锁的设计思想中，我们总结一下乐观锁和悲观锁的适用场景：
乐观锁 适合 读操作多 的场景，相对来说写的操作比较少。它的优点在于 程序实现 ， 不存在死锁
问题，不过适用场景也会相对乐观，因为它阻止不了除了程序以外的数据库操作。
悲观锁 适合 写操作多 的场景，因为写的操作具有 排它性 。采用悲观锁的方式，可以在数据库层
面阻止其他事务对该数据的操作权限，防止 读 - 写 和 写 - 写 的冲突
4.按照加锁的方式进行划分：显式锁和隐式锁
5.全局锁
锁定整个数据库，当你需要让整个数据库处于只读状态，其他线程的DML和DDL操作会被阻塞，全局锁的典型使用场景是：做全库逻辑备份
6.死锁
两个事务都持有对方需要的锁，并且在等待对方释放，并且双方都不会释放自己的锁
如何处理死锁？
1.等待，直到超时（可以设置超时时间）
2.死锁的检测机制（wait-for grap算法）
如何避免死锁：
1.合理设计索引，是业务SQL尽可能通过索引定位更少的行，减少锁竞争
2.调整业务逻辑SQL执行顺序，避免更新/删除长时间持有锁的SQL在事务前面
3.避免大事务，可以将大事务拆分成多个小事务来进行处理，小事务缩短锁定资源的时间，发生锁冲突的几率更小
4.在并发比较高的系统中，不要显示的加锁，特别是在事务中显示加锁
5.降低隔离级别
若有收获，就点个赞吧
0 人点赞
