【数据库——锁】

前言：

你把它不放在心上，你就永远不清楚它。这是这个阶段自己最深刻的体会，当我们学习知识的时候，就是要亲密的接触它，这样收获的知识才是自己的！

核心：

首先先来了解一下事务的缺陷：

一、事务的缺陷

1.丢失更新（lose update）

两个进程都是先读取后更新，一个进程不知道另一个进程的存在，一个进程可能会覆盖另一个进程的更新。

2.脏读（dirty read）

是指读未提交的数据。一个进程更新了数据但在另一个进程读取相同的数据前未提交的更新。

3.不可重复读（unrepeateable read）

也称为不一致的分析，同一个事务的两次读取中，进程读取相同的资源得到不同的值。

4.幻读(Phantom Read)

当事务不是独立执行时发生的一种现象。A事务修改了数据，B事务也修改了数据，事务提交后，A事务的用户发现表中还没有被修改的数据行，好像发生了幻觉一样。

为了防止这些问题，引入数据库并发控制技术。锁是并发控制技术的一种。由此引出了锁，接下来，我们一起来看看锁。

二、锁的概念

锁的基本原则：允许一个事务更新数据。

三、锁的类别

1.共享锁（shared lock,S）：

情景：用于不更改数据的操作（只读操作）

特点：可以被其他用户读取，但无法被其他用户修改。

2.更新锁（update lock，U）：

情景：用于可能被更新的资源中，防止多个事务在读取、锁定以及随后可能进行的更新操作时发生死锁。

特点：同一时刻只能有一个事务可以获得资源的更新锁。

3.排他锁（exclusive lock,X）：

情景：用于数据修改操作。

特点：与所有锁模式互斥，以确保不会同时对同一资源进行多重更新。

4.意向锁（intent lock）：

情景：用于建立锁的层次结构

特点：获取共享锁或排他锁

5.架构锁（Schema locks）：

情景：在执行依赖于表架构的操作时使用

6.大容量更新锁（bulk update lock,BU）：

特点：允许多个会话向表中大容量加载数据，同时阻塞进程对该表执行大容量加载以外的操作。

 

四、死锁及其防止

处理死锁的最好方法，防止死锁的发生。需要遵循的原则：

1.尽量避免并发的执行涉及到数据库修改数据的语句（少并发修语句）

2.要求每个事务一次就将所有要使用的数据全部加锁，否则就不予执行（一次加锁）

3.预先规定一个加锁的顺序。所有的事务，都必须按这个顺序对数据进行加锁。（规定加锁顺序）

4.每个事务的执行时间不可太长，尽量缩短事务的逻辑处理过程，及早提交或回滚事务。对程序段长的事务可以考虑将其分割为几个事务。（缩短处理过程）

5.对一般不要修改的SQL Server事务的默认级别。不推荐强加锁。（默认级别）

总结：

不断总结中，感谢大家的阅读！