数据库各种锁

整理来自鲜二娃

Java高并发，如何解决，什么方式解决

https://www.cnblogs.com/lr393993507/p/5909804.html

锁级别分类 - 共享锁 & 排他锁 & 意向锁

锁粒度分类 - 行级锁&表级锁&页级锁

共享锁（Share Lock）

SELECT ... LOCK IN SHARE MODE;
其他线程可以对数据再加共享锁，也可以读取使用了共享锁的表，而且这些线程读取的是同一个版本的数据。

排他锁（Exclusive Lock）

SELECT ... FOR UPDATE;
当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请排他锁，否则会被阻塞。

意向锁是表级锁，其设计目的主要是为了在一个事务中揭示下一行将要被请求锁的类型。

关于MySQL的几种锁机制的使用介绍

https://www.2cto.com/database/201805/742946.html

MyISAM

MyISAM在执行查询语句之前会自动给涉及的所有表加读锁（隐式锁），在执行更新操作之前会自动给涉及的表加写锁（隐式锁），这个过程并不需要用户干预。MyISAM在自动加锁时，总是一次性获得SQL语句所需的全部锁，这也是MyISAM表不会出现死锁的原因。
用户模拟事务操作时可以用LOCK TABLE命令给MyISAM表显式加锁

InnoDB

另外，为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁。
对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；
对于普通SELECT语句，InnoDB不会加任何锁；
事务可以通过以下语句显示给记录集加共享锁或排他锁，
共享锁（S）：SELECT * FROM table_name WHERE … LOCK IN SHARE MODE。

排他锁（X）：SELECT * FROM table_name WHERE … FOR UPDATE。

对于锁定行记录后需要进行更新操作的应用，应该使用排他锁。
InnoDB行锁是通过给索引上的索引项加锁实现的，这意味着只有通过索引条件检索数据，InnoDB才使用行级锁，否则InnoDB使用表锁。

InnoDB存储引擎实现了标准的行级锁，读锁和写锁（并行读串行写），还有表级锁，间隙锁。。。

间隙锁（Next-Key锁）

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）。

InnoDB使用间隙锁的目的，一方面是为了防止幻读，以满足相关隔离级别的要求，对于上面的例子，要是不使用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；另外一方面，是为了满足其恢复和复制的需要。

mysql的悲观锁 - 以行锁做示例

每次拿数据的时候都认为别的线程会修改数据，所以每次拿数据的时候都会给数据上锁。
上锁之后，当别的线程想要拿数据时，就会阻塞。直到给数据上锁的线程将事务提交或者回滚。
传统的关系数据库里面很多用了这种锁机制，比如行锁，表锁，共享锁，排他锁等，都是在做操作之前先上锁。

Java事务级别主要是为了解决不同事务之间的数据干扰问题

数据干扰主要有：脏读（读了其他事务未提交的数据）读取已提交内容（读取别的事务已经提交的数据），幻读（读取其他事务新插入的数据）
解决：启用封锁协议（就是灵活加排他锁）：一级封锁协议，二级封锁协议，三级封锁协议，串行化

一级封锁协议Read Uncommitted（读取未提交内容）：

改数据加排他锁（事务结束释放），查数据不加任何锁
查询时不要求加锁，所以可以读数据

二级封锁协议Read Committed（读取已提交内容）：

改数据依然是加的排他锁（事务结束释放）
查数据仅在查询发起到查询返回数据这短暂的时间加共享锁，查到之后锁立即解除，不会等到事务提交。
由于a的排他锁是事务提交时才会解除，所以在a提交之前，b都查不到数据的（此查询加共享锁会等待），查数据就会阻塞。

三级封锁协议Repeatable Read（可重复读）：

改数据加排他锁
查询相关数据加共享锁了，而且是直到本事务提交才释放。（在此期间的其他事物不能对加锁数据进行修改）

串行化Serializable（串行化）：

串行化是对整表加锁。读数据时对整表加共享锁，修改数据对整表加排他锁。