隔离级别

线上某服务时不时报出如下异常（大约一天二十多次）：“Deadlock found when trying to get lock;”。 Oh, My God! 是死锁问题。尽管报错不多，对性能目前看来也无太大影响，但还是需要解决，保不齐哪天成为性能瓶颈。 为了更系统的分析问题，本文将从死锁检测、索引隔离级别与锁的关系、死锁成因、问题定位这五个方面来展开讨论。 图1 应用日志 1 死锁是怎么被发现的？ 1.1 死锁成因&&检测方法 左图那两辆车造成死锁了吗？不是！右图四辆车造成死锁了吗？是！ 图2 死锁描述 我们mysql用的存储引擎是innodb，从日志来看，innodb主动探知到死锁，并回滚了某一苦苦等待的事务。问题来了，innodb是怎么探知死锁的？ 直观方法是在两个事务相互等待时，当一个等待时间超过设置的某一阀值时，对其中一个事务进行回滚，另一个事务就能继续执行。这种方法简单有效，在innodb中，参数innodb_lock_wait_timeout用来设置超时时间。 仅用上述方法来检测死锁太过被动，innodb还提供了wait-for graph算法来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。 1.2 wait-for graph原理 我们怎么知道上图中四辆车是死锁的？他们相互等待对方的资源，而且形成环路

本文实验的测试环境：Windows 10+cmd+MySQL5.6.36+InnoDB 一、事务的基本要素（ACID） 　　 1、原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。 　　 2、一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。 　　 3、隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。 　　 4、持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。 二、事务的并发问题 　　1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据 　　2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。 　　3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级

根据自身 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

一、关于事务的隔离级别： 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改完分数结束后发现还有一条记录没有改过来,就好像发生了幻觉一样. 小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表 三

事务的定义 事务 ：数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作; 事务是一组不可再分割的操作集合（工作逻辑单元）。 典型事务使用场景 ：转账 update user_account set balance = balance - 1000 where userID = 3; update user_account set balance = balance + 1000 where userID = 1; MySQL 开启事务 ： /* BEGIN / START TRANSACTION --手工 COMMIT / ROLLBACK --事务提交或回滚 SET SESSION autocommit = ON/OFF --设定会话级别事务是否自动开启 */ MySQL 默认是开启事务的，通过 SHOW VARIABLES like 'autocommit'; 可以查看 MySQL 的事务开启情况。 在 autocommit = ON（自动提交事务）的情况下，可以执行 BEGIN; 或者 START TRANSACTION; 命令，改为手动提交事务，执行完 SQL 语句后，需要通过 COMMIT 命令提交事务，或者通过 ROLLBACK 命令回滚事务。 在 autocommit = OFF（手动提交事务）的情况下，执行完 SQL 语句后，需要通过 COMMIT

写在前面 这篇文章是在网络上看到其他作者的优秀博文，自己消化理解之后所做的记录。文章基于 MySQL 中的 InnoDB 存储引擎。 原博文地址： 点我 锁 锁知识概览 我们先看一张锁的概览图，方便后续的讲述： 我们的程序在一般情况下还是可以跑得好好的。因为这些锁数据库 隐式 帮我们加了；只在某些特定的场景下，才需要程序员手动加锁。 在执行「查询语句」 SELECT 前，会自动给涉及的所有表加「表级锁」中的 读锁 ；在执行「更新操作」 UPDATE、DELETE、INSERT 前，会自动给涉及的表加「表级锁」中的 写锁 对于 InnoDB ,且 使用了索引 的「更新操作」 UPDATE、DELETE、INSERT 语句；这时 InnoDB 会将「表锁」转换成「行锁」，也就是会自动给涉及数据集加「行级锁」中的 排他锁（X) 注意 ：InnoDB 只有通过「索引」检索数据才使用「行级锁」，否则，InnoDB将使用表锁；也就是说，InnoDB 的 行锁基于索引 。 一种特殊情况 如果我们对表中的某列加的是「普通索引」，那也就意味着： 索引列属性可能重复 。 对于普通索引，当 重复率高 时，MySQL 不会把这个普通索引当做索引，即会造成一个没有索引的SQL，从而 形成表锁 。 锁的分类 从上图中，以锁的粒度出发，我们可以看到锁分为「表级锁」和「行级锁」 『表锁』：开销小，加锁快

事务是逻辑上的一组操作，要么都执行，要么都不执行。 事务最经典的、经常被拿出来说的例子就是转账了。假如小花要给小白转账1000元，这个转账会涉及到两个关键操作就是：将小花的余额-1000，将小白的余额+1000。但是万一在这两个操作之间突然出现了错误，比如银行系统突然断电，或突然宕机崩溃，都可能会导致小花的余额-1000之后，小白的余额却没有+1000，这样小花和小白就都不开心了。事务就是为了保证这两个关键操作要么都成功，要么都要失败的一个机制，都成功也就完成了转账，都失败也不会造成小花的损失。 事务的特性 事务是有四个特性（ACID）的，分别是原子性、一致性、隔离性和持久性。 原子性（Atomity）： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用。 一致性（Consistency）： 执行事务的前后，数据保持一致。 隔离性（Isolation）： 并发访问数据库时，一个用户的事务不能被其他事务所干扰，各个并发事务对于数据库来说都是独立的。 持久性（Durable）： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。 并发事务带来的问题 在典型的应用程序中，如果是多个事务并发运行，经常会出现多个事务操作相同的数据来完成各自的任务（多个用户对统一数据进行操作）的场景。 虽然并发是必须的

ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性） 事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在 MySQL 中，事务支持是在引擎层实现的。MySQL 是一个支持多引擎的系统，但并不是所有的引擎都支持事务， MyISAM 引擎就不支持事务。 当数据库上有多个事务同时执行的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题。 隔离级别 　　隔离得越严实，效率就会越低。因此很多时候，我们都要在二者之间寻找一个平衡点。 读未提交（read uncommitted）：一个事务还没提交时，它做的变更就能被别的事务看到。 读提交（read committed）：一个事务提交之后，它做的变更才会被其他事务看到。 可重复读（repeatable read）：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。 串行化（serializable ）：串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。 　　 　　 　　1. 若隔离级别是