SQL-事务

事务的隔离级别

        数据库事务的隔离级别有4种，由低到高分别为Read uncommitted 、Read committed 、Repeatable read 、Serializable 。而且，在事务的并发操作中可能会出现脏读，不可重复读，幻象读。

隔离级别	脏读	不可重复读	幻象读
Read uncommitted	✔	✔	✔
Read committed	✘	✔	✔
Repeatable read	✘	✘	✔
Serializable	✘	✘	✘

Read uncommitted（ 未提交读 ）

       一个事务可以读取另一个未提交事务的数据。

       事例：老板要给程序员发工资，程序员的工资是 3.6万 /月。但是发工资时老板不小心按错了数字，按成 3.9万 /月，该钱已经打到程序员的户口，但是事务还没有提交，就在这时，程序员去查看自己这个月的工资，发现比往常多了 3千 元，以为涨工资了非常高兴。但是老板及时发现了不对，马上回滚差点就提交了的事务，将数字改成 3.6万 再提交。

       分析：实际程序员这个月的工资还是 3.6万，但是程序员看到的是 3.9万 。他看到的是老板还没提交事务时的数据。这就是脏读。

Read committed（ 提交读 ）

       一个事务要等另一个事务提交后才能读取数据。

       事例：程序员拿着信用卡去享受生活（ 卡里当然是只有 3.6万 ），当他埋单时（ 程序员事务开启 ），收费系统事先检测到他的卡里有 3.6万，就在这个时候！！程序员的妻子要把钱全部转出充当家用，并提交。当收费系统准备扣款时，再检测卡里的金额，发现已经没钱了（ 第二次检测金额当然要等待妻子转出金额事务提交完 ）。程序员就会很郁闷，明明卡里是有钱的…

       分析：这就是读提交，若有事务对数据进行更新（ UPDATE ）操作时，读操作事务要等待这个更新操作事务提交后才能读取数据，可以解决脏读问题。但在这个事例中，出现了一个事务范围内两个相同的查询却返回了不同数据，这就是不可重复读。

Repeatable read（ 可重复读 ）

       重复读，就是在开始读取数据（ 事务开启 ）时，不再允许修改操作

       事例：程序员拿着信用卡去享受生活（卡里当然是只有3.6万），当他埋单时（ 事务开启，不允许其他事务的 UPDATE 修改操作 ），收费系统事先检测到他的卡里有 3.6万。这个时候他的妻子不能转出金额了。接下来收费系统就可以扣款了。

       分析：重复读可以解决不可重复读问题。写到这里，应该明白的一点就是，不可重复读对应的是修改，即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入插 NSERT 操作，而不是 UPDATE 操作。

Serializable 序列化

       Serializable 是最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。

---

锁

       锁可以防止事务的并发问题，在多个事务访问下能够保证数据库完整性和一致性。

共享（ S ）锁

      用于不更改或不更新数据的读取操作，如 SELECT 语句。

      理解：允许并发事务读取（ SELECT ）的一个资源，资源上存在共享锁时，任何事务不能修改数据，一旦已经读取数据，便立即释放资源上的共享锁。

      就相当于多个设备可以同时读取数据库数据，都可以对其加共享锁；但若某一设备想修改数据，则需要等所有设备查询完成后，在都释放共享锁之后，加自己的更新锁

举例：

      当某人查询某张表的一条记录时，就会在该记录上放置共享锁，在而其他人也要查询这张表的此记录时，因为共享锁彼此不互斥，所以也可以再次放置共享锁，也就是说SQL SERVER 允许不同连接同时读取相同的数据。如果此时有人要更新此记录，因为独占锁与共享锁互斥，所以无法放置独占锁，要等到所有读取此记录的人都读取完毕，释放了共享锁，更新数据的人才能对该记录设置独占锁，并进一步更新数据。

      一般情况下，在默认的事务隔离级别下，当数据读取完毕，SQL SERVER 就会释放共享锁，除非有特别的设置。

更新（ U ）锁

      在修改操作的初始化阶段用来锁定要被修改的资源，避免使用共享锁造成的死机现象。

      一次只有一个事务可以获取资源的更新锁。如果事务修改资源，则更新锁（ U ）转换为排他锁（ X ）

举例：

        当查询一条记录后，要将此内容更新（ Update 语句加上 Where 条件 ），一定会先查找记录，在查找的过程中就会对相关的记录放置共享锁，等找到相应的记录之后，SQL SERVER 会先对记录放置更新锁，以避免发生死锁。因为共享锁与更新锁并不互斥，如果两个人同时对同一条记录放置共享锁，先进行更新的人，可以在别人也对同一条记录放置了共享锁时，继续放置更新锁，但因为更新锁互斥，所以当另一个人想再放置更新锁时，将无法设置，而进入停止等待状态。

排他（ X ）锁

      用于数据修改操作，例如 INSERT、UPDATE 或 DELETE。 确保不会同时对同一资源进行多重更新。

举例：

      UPDATE 语句可能根据与一个表的联接修改另一个表中的行。 在此情况下，除了请求更新行上的独占锁之外，UPDATE 语句还将请求在联接表中读取的行上的共享锁。

意向锁

      用于建立锁的层次结构。 意向锁包含三种类型：意向共享（ IS ）、意向排他（ IX ）和意向排他共享（ SIX ）。

      意向共享（ IS ）：通过在资源上放置 IS 锁，表明事务的意向时读取层次结构中的部分（ 而不是全部 ）底层资源。

      意向排他（ IX ）：通过在资源上放置 IX 锁，表明事务的意向时修改层次结构中的部分（ 而不是全部 ）底层资源。

      意向排他共享（ SIX ）:IS锁 和 IX锁 的综合运用，每一资源在一个时间段内只能有一个 SIX锁。

举例：

      在表的数据页或数据行上请求共享锁（ S锁 ）之前，在表级( 或页级 )请求共享意向锁，以防止另一个事务随后在包含那一页的表上尝试放置独占锁（ X锁 ）。

架构锁

      在执行依赖于表架构的操作时使用。 架构锁包含两种类型：架构修改 ( Sch-M ) 和架构稳定性 ( Sch-S )。

大容量更新（ BU ）锁

      在向表进行大容量数据复制且指定了 TABLOCK 提示时使用。