事务隔离级别

锁的概述 一. 为什么要引入锁 多个用户同时对数据库的并发操作时会带来以下数据不一致的问题: 丢失更新 A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果,比如订票系统 脏读 A用户修改了数据,随后B用户又读出该数据,但A用户因为某些原因取消了对数据的修改,数据恢复原值,此时B得到的数据就与数据库内的数据产生了不一致 不可重复读 A用户读取数据,随后B用户读出该数据并修改,此时A用户再读取数据时发现前后两次的值不一致 并发控制的主要方法是封锁,锁就是在一段时间内禁止用户做某些操作以避免产生数据不一致 二 锁的分类 锁的类别有两种分法： 从数据库系统的角度来看：分为独占锁（即排它锁），共享锁和更新锁 MS-SQL Server 使用以下资源锁模式。 锁模式 描述 共享 (S) 用于不更改或不更新数据的操作（只读操作），如 SELECT 语句。 更新 (U) 用于可更新的资源中。防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生常见形式的死锁。 排它 (X) 用于数据修改操作，例如 INSERT、UPDATE 或 DELETE。确保不会同时同一资源进行多重更新。 意向锁 用于建立锁的层次结构。意向锁的类型为：意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。 架构锁 在执行依赖于表架构的操作时使用。架构锁的类型为：架构修改

(1) HOLDLOCK: 在该表上保持共享锁，直到整个事务结束，而不是在语句执行完立即释放所添加的锁。 　　 (2) NOLOCK：不添加共享锁和排它锁，当这个选项生效后，可能读到未提交读的数据或“脏数据”，这个选项仅仅应用于SELECT语句。 　　 (3) PAGLOCK：指定添加页锁（否则通常可能添加表锁）。　 　　 (4) READCOMMITTED用与运行在提交读隔离级别的事务相同的锁语义执行扫描。默认情况下，SQL Server 2000 在此隔离级别上操作。 (5) READPAST: 跳过已经加锁的数据行，这个选项将使事务读取数据时跳过那些已经被其他事务锁定的数据行，而不是阻塞直到其他事务释放锁，READPAST仅仅应用于READ COMMITTED隔离性级别下事务操作中的SELECT语句操作。　 　　 (6) READUNCOMMITTED：等同于NOLOCK。　 　　 (7) REPEATABLEREAD：设置事务为可重复读隔离性级别。　 　　 (8) ROWLOCK：使用行级锁，而不使用粒度更粗的页级锁和表级锁。　　 　　 (9) SERIALIZABLE：用与运行在可串行读隔离级别的事务相同的锁语义执行扫描。等同于 HOLDLOCK。　 　　 (10) TABLOCK：指定使用表级锁，而不是使用行级或页面级的锁，SQL Server在该语句执行完后释放这个锁

前言 消息队列 在互联网技术存储方面使用如此广泛，几乎所有的后端技术面试官都要在 消息队列 的使用和原理方面对小伙伴们进行360°的刁难。 作为一个在互联网公司面一次拿一次Offer的面霸，打败了无数竞争对手，每次都只能看到无数落寞的身影失望的离开，略感愧疚（ 请允许我使用一下夸张的修辞手法 ）。 于是在一个寂寞难耐的夜晚， 暖男 我痛定思痛，决定开始写 《吊打面试官》 系列，希望能帮助各位读者以后面试势如破竹，对面试官进行360°的反击，吊打问你的面试官，让一同面试的同僚瞠目结舌，疯狂收割大厂Offer！ 捞一下 上一期，简单的介绍了一下 消息队列 的基础知识，里面有消息队列的应用场景，以及使用之后可能带来的问题，但是上期没对怎么解决这些问题做回答，因为要控制篇幅嘛（明明是自己觉得MQ写不了多少期，要多怼一期出来！渣男） 咳咳，我们言归正传，没看的朋友去看一下，有助于这期的阅读： 《吊打面试官》系列-消息队列基础 面试开始 一个风度翩翩，穿着格子衬衣的中年男子，拿着一个满是划痕的mac向你走来，看着铮亮的头，心想着肯定是尼玛顶级架构师吧！但是我们看过暖男敖丙的系列，腹有诗书气自华，虚都不虚。 没错小伙子还是我，上次话说一半你就溜了，这次我非得好好的问问你。 好的面试官，因为上次着急，敖丙的系列更新了所以赶回家去看了！ 我信你个鬼，我们开始吧，上次说到了消息队列的消息重复消费

根据自身 Sql Server 的情况来自定义 事务隔离级别，将会更加的满足需求，或提升性能。例如，对于逻辑简单的 Sql Server,完全可以使用 read uncommitted 模式，来减少死锁，减少堵塞， 提升性能和响应。对于此种应用场景应该是蛮多的，但是却没有一个全局设置，你妹呀！ 这个功能真的很强大，但是不知道微软为什么把它的最大作用域定义为 当前链接，蛋疼，真的很蛋疼，没法全局设置，下面也尽可能详细的解释如何少设置，多舒服的使用吧 查看 当前 Sql Server 事务隔离级别 的设置： DBCC Useroptions -> isolation level 这一项的 Value 既是当前的设置值 但是我不得不说，这个命令几乎是废物，为什么呢，因为 事务隔离级别 的作用域是 当前链接，也就是，你查看的是当前链接的 级别，但是sql server 同时 150+ 个链接是很正常的，其他链接呢，你说蛋疼不，我X 设置Sql Server 事务隔离级别 Sql Server 事务隔离级别 的设置也同样很蛋疼，很纠结，很恶心。但是稍微好一点的是，其设置可以在多个场合，多种方式设置，稍微弥补了一点点. 1. Transact-SQL 语句中的设置 就是在当前 SQL 语句中，设置的事务隔离级别只影响当前 sql 语句, 有两种方式： -- the first method

事务 ACID 特性 原子性 （ A tomicity）: 事务中的所有操作，要么全部成功，要么全部失败回滚到最初状态，不会结束在中间的某个环节 一致性 （ C onsistency）: 事务开始之前和结束之后，数据库的完整性没有被破坏，写入的数据必须完全符合所有的预设约束，触发器，级联回滚等等 隔离性 （ I solation）: 数据库并发事务同时对其数据进行读写和修改，隔离性可以防止并发事务交叉执行而导致数据不一致 持久性 （ D urability）: 事务处理结束后，对数据的修改是永久的，即使系统故障也不会丢失 事务的并发问题 脏读 : 一个事务读取另一个事务未更新的数据 不可重复读 : 一个事务读取同一个行数据两次得到不同的结果 幻读 : 两次范围查询，第二次查询出现第一次更多或者更少的数据 丢失更新1 : 两个事务同时更新一行数据，其中一个事务撤销时覆盖另一个事务 丢失更新2 : 两个事务同时更新一行数据，其中一个事务提交时覆盖另一个事务 事务的隔离级别 读未提交 （Read uncommitted）: 允许脏读/不可重复读/幻读/丢失更新2；修改数据时加行级共享锁至事务结束 读已提交 （Read committed）: 允许不可重复读/幻读/丢失更新2，一个事务只能读取另一个事务已提交的数据；修改数据时加行级排它锁至事务结束 可重复读 （Repeatable

一、关于事务的隔离级别： sql定义四种隔离级别（由低到高） 1 Read Uncommitted 读取未提交内容 2 Read Committed 读取提交内容 3 Repeatable Read 可重读 4 Serializable 可串行化 二、不同隔离级别所面对的问题 四种隔离级别通过不同的锁类型实现，在读取同一个数据，就容易发生问题。 问题有三种 ：脏读，不可重复读，幻读。 不同的隔离级别可能产生的问题也不同 隔离级别 脏读 不可重复读 幻读 Read Uncommitted √ √ √ Read Committed × √ √ Repeatable Read × × √ Serializable × × × 三、产生问题的原因 脏读：首先有行记录a，事务A将记录a修改为a1，但尚未提交（可能会提交失败）。事务B读取到了未提交的数据a1。 原因：因为一旦事务A回滚，那么事务B读取到的a1就是无效数据。 不可重复读：同一事务对一条记录读取2次，得到的结果不一致。 原因：两次读取的过程中，事务B对这条记录进行了修改。 幻读：事务A 读取一条where子句的结果集，2次读取得到的记录多出n条。 原因：两次读取过程中，事务B对数据库插入新行，并且满足事物A的where 条件。 oracle数据库 只支持Read Committed 和 Serializable，默认第二种;

1.事务特性ACID 原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持续性（Durability） 2.事务隔离级别 读未提交（Read Uncommited）、读已提交（Read Committed）、可重复读（Repeatable Read）、序列化（Serializable） 3.可能出现问题表格 ------------------------- 脏读 不可重复读 幻读 RU true true true RC false true true RR false false true S false false false ------------------------- 4.RU和S在实际应用中基本不用，RU会导致脏读，数据不可置信。S锁级别太高，性能差 5.Mysql默认隔离级别为RR，Oracle等其他默认级别为RC，Mysql推荐binlog格式为row 6.Mysql默认级别为RR的原因是，在Mysql早期，binlog只有statement格式，对于master/slave主从复制可能出现顺序错误的bug 后期Mysql推出了row级别日志解决了此问题，所以所有业务型数据库推荐隔离级别为RC 7.推荐隔离级别为RC的原因（RC优于RR的原因） -RC比RR更不容易出现死锁 -在索引未达成的情况下，RR锁全表

MySQL的四种事务隔离级别 一:事务的基本要素 原子性(Atomic):事务开始后所有操作,要么全部做完,要么全部不做,不可能停滞在中间环节.事务执行过程中出错,会回滚到事务开始前的状态,所有的操作就像没有发生一样. 一致性(consistent):事务开始前和结束后,数据库的完整性约束没有被破坏.比如A向B转账,不可能A扣了钱,B却没有收到. 隔离性(isolation):同一时间,只允许一个事务请求同意数据,不同事务之间彼此没有任何干扰.比如A正在从一张银行卡取钱,在A取钱的过程结束前,B不能 持久性(durable):事务完成后,事务对数据库的所有更新将被保存到数据库,不能回滚. 二:事务的并发问题 脏读:事务A读取了事务B更新的数据,然后B回滚操作,那么A读取到的数据是脏数据 不可重复读:事务A多次读取同一数据,事务B在事务A多次读取的过程中,对数据做了更新并提交,导致事务A多次读取同一个数据时,结果不一致 幻读:系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级,但是系统管理员B就在这个时候插入了一条具体分数的记录,当系统管理员A改完分数结束后发现还有一条记录没有改过来,就好像发生了幻觉一样. 小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表 三

一. 乐观锁 乐观锁并不是真实存在的锁，而是在更新的时候判断此时的库存是否是之前查询出的库存，如果相同，表示没人修改，可以更新库存，否则表示别人抢过资源，不再执行库存更新。类似如下操作。 # sql实现语句update tb_apple set stock=2 where id=1 and stock=7;# djano中ORM实现语句 apple.objects.filter(id=1, stock=7).update(stock=2) 二.乐观锁下单逻辑 第一步 : 下单逻辑 def create(self, validated_data): """ 保存订单 """ # 获取当前下单用户 user = self.context['request'].user # 组织订单编号 20170903153611+user.id # timezone.now() -> datetime order_id = timezone.now().strftime('%Y%m%d%H%M%S') + ('%09d' % user.id) address = validated_data['address'] pay_method = validated_data['pay_method'] # 生成订单 with transaction.atomic(): # 创建一个保存点 save_id

一.事务 定义：所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。 准备工作：为了说明事务的ACID原理，我们使用银行账户及资金管理的案例进行分析。 二.ACID ACID，是指在可靠数据库管理系统（DBMS）中，事务(transaction)所应该具有的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）.这是可靠数据库所应具备的几个特性.下面针对这几个特性进行逐个讲解. 三.原子性 原子性是指事务是一个不可再分割的工作单位，事务中的操作要么都发生，要么都不发生。 1.案例 A给B转帐100元钱 2.分析 在事务中的扣款和加款两条语句，要么都执行，要么就都不执行。否则如果只执行了扣款语句，就提交了，此时如果突然断电，A账号已经发生了扣款，B账号却没收到加款，在生活中就会引起纠纷。 3.解决方法 在数据库管理系统（DBMS）中，默认情况下一条SQL就是一个单独事务，事务是自动提交的。只有显式的使用start transaction开启一个事务，才能将一个代码块放在事务中执行。保障事务的原子性是数据库管理系统的责任，为此许多数据源采用日志机制。例如，SQL Server使用一个预写事务日志，在将数据提交到实际数据页面前，先写在事务日志上。 四.一致性