隔离级别

oracle查看被锁的表和解锁 --以下几个为相关表 SELECT * FROM v$lock; SELECT * FROM v$sqlarea; SELECT * FROM v$session; SELECT * FROM v$process ; SELECT * FROM v$locked_object; SELECT * FROM all_objects; SELECT * FROM v$session_wait; --查看被锁的表 select b.owner,b.object_name,a.session_id,a.locked_mode from v$locked_object a,dba_objects b where b.object_id = a.object_id; --查看那个用户那个进程照成死锁 select b.username,b.sid,b.serial#,logon_time from v$locked_object a,v$session b where a.session_id = b.sid order by b.logon_time; --查看连接的进程 SELECT sid, serial#, username, osuser FROM v$session; --3.查出锁定表的sid, serial#,os_user_name,

前言 中秋刚过,大家是不是还没充中秋的假日里缓过来?三天假期里,我深入窥探了Innodb中可重复读与幻读,非常有意思,分享给大家,作为大家工作前的开胃小菜,希望有所帮助. 每次谈到数据库的事务隔离级别,大家一定会看到这张表. 其中, 可重复读 这个隔离级别,有效地防止了脏读和不可重复读,但仍然可能发生幻读, 可能 发生幻读就表示 可重复读 这个隔离级别防不住幻读吗? 我不管从数据库方面的教科书还是一些网络教程上,经常看到RR级别是可以重复读的,但是无法解决幻读,只有可串行化(Serializable)才能解决幻读,这个说法是否正确呢? 在这篇文章中,我将重点围绕MySQL中 可重复读（Repeatable read）能防住幻读吗? 这一问题展开讨论,相信看完这篇文章后,你一定会对事务隔离级别有新的认识. 我们的数据库中有如下结构和数据的 Users 表,下文中我们将对这张表进行操作, 长文预警,读完此篇文章,大概需要您二十至三十分钟. 什么是幻读? 在说幻读之前,我们要先来了解脏读和不可重复读. 脏读 当一个事务读取到另外一个事务修改但未提交的数据时，就可能发生脏读。 在我们的例子中，事务2修改了一行，但是没有提交，事务1读了这个没有提交的数据。现在如果事务2回滚了刚才的修改或者做了另外的修改的话，事务1中查到的数据就是不正确的了,所以这条数据就是脏读。 不可重复读 “不可重复读

MySQL8中隔离级别的变量跟之前的版本不一样，之前是tx_isolation，MySQL8改成了transaction_isolation。查看当前隔离级别的命令是 select @@global.transaction_isolation,@@transaction_isolation; 返回结果 +--------------------------------+-------------------------+ | @@global.transaction_isolation | @@transaction_isolation | +--------------------------------+-------------------------+ | READ-COMMITTED | REPEATABLE-READ | +--------------------------------+-------------------------+ 1 row in set (0.00 sec) mysql的默认隔离级别是可重复读，但其实对高并发业务来说，可重复读并不是最合适的，最合适的是读提交，主要是因为MySQL 5.0之前，MySQL的主从复制在度提交这个隔离级别下是有bug的。 修改MySQL隔离级别命令： 修改全局隔离级别为读提交： SET GLOBAL

前言 我前段时间在写代码的时候，经常考虑并发问题，对事物的安全性、隔离级别需要更深的了解，所以翻看了网上绝大部分关于事务的文章。但是看了之后还是有些疑惑，例如事务的四种隔离级别，虽然有些文章举出了生动的例子，但并没有提到编程中的如何选择使用。 大部分介绍事务的文章，都是介绍什么事务隔离级别的、各种锁的概念，好像举得概念越多，就显示作者了知识更丰富一样，然而并没有实际编程的例子，就像英文教科书般将本该实际运用的东西变成一种学术，就算看懂讲是什么东西也没办法使用。这种 教科书式、百科式的文章害人不浅，因此我才写这篇文章。 事务隔离级别 事 务 简单来说就是要么一起过，要么全部取消，保证数据的完整性，在普通情况下，事 务 就是这么简单，提交回滚罢了。然而遇到并发问题，数据安全问题，这点了解是不够的。 事 务 有4种隔离级别，为什么是4种而没有5种、6种？可能是研究数据库的鼻祖们总结最后得出来的吧。那么下面我要先引用网上绝大部分关于这4种级别的介绍，以下为网上摘抄。 在介绍4种事 务 隔离级别前，需要三个概念： ‍ 1. 脏读： 一个事务读取到另一个事务尚未提交的数据。 ‍ 2. 不可重复读： 同一事务，两次读取同一数据，得到不同的结果。 ‍ 3. 幻读：同一事务，用相同的条件读 ‍ 取两次，得到的结果集数据条数不同（数据条数多了或者少了）。 然后为了解决这些个问题，数据库有了4种隔离级别

一．什么是事务 事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。 二．事务的 四个特性（ ACID ） 事务具有四个特性：原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）和持久性（ Durability ）。这四个特性简称为 ACID 特性。 1 、 事务的原子性 (Atomicity) 原子性要求事务所包含的全部操作是一个不可分割的整体，这些操作要么全部提交成功，要么只要其中一个操作失败，就全部不执行。 2 、事务的一致性 (Consistency) 一致性要求事务所包含的操作不能违反数据资源的一致性检查，数据资源在事务执行之前处于一个数据的一致性状态，那么，事务执行之后也需要依然保持数据间的一致性状态。 例如： 对于一个证券系统来说，如果顾客银行账户和证券账户资金总和为10 万的话 ( 银行账户初始 8 万，证券账户初始 2 万 ) ，从银行账户的 8 万转账 5 万到证券账户的事务操作结束之后，银行账户会剩余 3 万，证券账户为 7 万，两个账户的总和依然是 10 万，如果事务操作结束后，整个数据状态不是这个样子，那么就说系统处于不一致状态，而使用事务其中一个目的就是为了避免这种不一致性状态的产生。 3 、事务的隔离性 (Isolation)

数据库中隔离级别的操作 设置隔离级别： set tx_isolation = 'READ-UNCOMMITTED' 查看隔离级别： select @@tx_isolation 一、Read Uncommitted -- 读取未提交内容 一个事务可以查看到未提交的内容 常产生脏读问题(脏读：读取到其他事务未提交(执行)的内容) 对同一数据表开启A、B两个事务(A、B事务交叉) start transaction A事务只查询数据表中内容，B事务做增删改操作但不commit(提交) A事务依旧可以查询到表中的数据改变(查询到未提交的内容--脏读) 二、Read Committed -- 读取提交内容 一个事务只能查看已提交的内容 常产生不可重复读的问题(不可重复读：同一事务中执行相同的select语句得到不同的结果) 对同一数据表开启A、B两个事务(A、B事务交叉) start transaction A事务只查询数据表中内容，B事务做增删改操作但不commit(提交) A事务查询不到表中的数据改变的内容 B事务提交 A查到的数据改变(A两次查询，产生不同的结果--不可重复读) 三、Repeatable Read -- 可重读 同一事务的多个实例并发读取数据时得到同一结果 MySQL的默认事务隔离级别 常产生幻读问题(幻读：多次读取时产生不同结果(幻影行)) 对同一数据表开启A

背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注： MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于InnoDB存储引擎，其他引擎的表现，会有较大的区别。 MVCC：Snapshot Read vs Current Read MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC ( Multi-Version Concurrency Control ) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。 在MVCC并发控制中，读操作可以分成两类：快照读 (snapshot read)与当前读

转载自何登成的技术博客：http://hedengcheng.com/?p=771 背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注： MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于InnoDB存储引擎，其他引擎的表现，会有较大的区别。 MVCC：Snapshot Read vs Current Read MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC ( Multi-Version Concurrency Control ) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。

http://hedengcheng.com/?p=771 类似的文章：https://www.cnblogs.com/yelbosh/p/5813865.html 1.解释了为什么update insert delete 也属于当前读 2.分9种情况解释了rc rr级别下，当前读在mysql中是如何加锁的 2.1 select no update or share mode 操作在非seariable下均不加锁，采用的是快照读，mysql使用mvcc返回历史数据 2.2 对于当前读，分情况讨论 背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注： MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于InnoDB存储引擎，其他引擎的表现，会有较大的区别。 MVCC：Snapshot Read vs Current Read MySQL InnoDB存储引擎

转载 http://blog.csdn.net/opensure/article/details/46227695 MySQL 加锁处理分析 标签： Database Deadlock Lock MySQL 2015-05-29 11:14 1101人阅读 评论 (0) 收藏 举报 分类： mysql（1） 目录 (?) [+] 1 背景 1 1.1 MVCC：Snapshot Read vs Current Read 2 1.2 Cluster Index：聚簇索引 3 1.3 2PL：Two-Phase Locking 3 1.4 Isolation Level 4 2 一条简单SQL的加锁实现分析 5 2.1 组合一：id主键+RC 6 2.2 组合二：id唯一索引+RC 6 2.3 组合三：id非唯一索引+RC 7 2.4 组合四：id无索引+RC 8 2.5 组合五：id主键+RR 9 2.6 组合六：id唯一索引+RR 9 2.7 组合七：id非唯一索引+RR 9 2.8 组合八：id无索引+RR 11 2.9 组合九：Serializable 12 3 一条复杂的SQL 12 4 死锁原理与分析 14 5 总结 16 背景 MySQL /InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时