隔离级别

本文实验的测试环境：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等级

transaction本意是买卖、交易。数据库世界为了强调数据的原子性，中译为 事务。 SQL标准规定不同隔离级别下产生的问题不同，会出现脏读、幻读与不可重复读的现象。对应四种事务的隔离级别： Read UnCommitted 会出现脏读、幻读与不可重复读现象 ReadCommitted 只会出现幻读与不可重复读现象 Repeatable Read 只会出现幻读现象 Serializable 串行执行 不过，各种数据库实现对SQL标准支持不同。 解决脏读、幻读与不可重复读的现象的两种解决方案： 方案一：读操作使用mvcc，写操作加锁 mvcc也叫版本链。每条聚簇索引叶子节点的记录都有隐藏的列：trx_id与roll_pointer，每个事务都有唯一的id。在操作记录时，又会产生undo日志，undo日志形成的链表的引用就保存在roll_pointer位置。 在读取一条记录时，通过快照生成一个ReadView的结构，他会记录当前系统中正活动的事务id，遍历roll_pointer的版本链进行对比，如果ReadView里包含undo的事务id，则证明该事务并没有提交，不能采用此日志的处理结果。一直遍历得到的事务id不在ReadView里，并且小于ReadView的最小事务id(因为事务id有全局变量记录并递增，小的事务id说明产生的更早)的事务，则返回此事务处理后的结果。 简单的说

一.mysql事件隔离级别 1未提交读（READUNCOMMITTED） 另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据（脏读）( 隔离级别最低，并发性能高 ) 2…提交读（READCOMMITTED） 本事务读取到的是最新的数据（其他事务提交后的）。问题是，在同一个事务里，前后两次相同的SELECT会读到不同的结果（不重复读）。会出现不可重复读、幻读问题（锁定正在读取的行) 3.可重复读（REPEATABLEREAD） 在同一个事务里，SELECT的结果是事务开始时时间点的状态，因此，同样的SELECT操作读到的结果会是一致的。但是，会有幻读现象（稍后解释）。会出幻读（锁定所读取的所有行） 推荐Python大牛在线分享技术 扣qun：855408893 领域：web开发，爬虫，数据分析，数据挖掘，人工智能 零基础到项目实战，7天学习上手做项目 4.串行化（SERIALIZABLE） 读操作会隐式获取共享锁，可以保证不同事务间的互斥（锁表) 二.脏读、不可重复读、幻读、复读 1.脏读 当前事务读到的数据是别的事务想要修改成为的但是没有修改成功的数据 2.不可重复读 当前事务先进行了一次数据读取，然后再次读取到的数据是别的事务修改成功的数据，导致两次读取到的数据不匹配，也就照应了不可重复读的语义 3.幻读

1. 隔离级别 (1) 读不提交 (Read Uncommited ， RU) 这种隔离级别下，事务间完全不隔离，会产生脏读，可以读取未提交的记录，实际情况下不会使用。 (2) 读提交 (Read commited ， RC) 仅能读取到已提交的记录，这种隔离级别下，会存在幻读现象，所谓幻读是指在同一个事务中，多次执行同一个查询，返回的记录不完全相同的现象。幻读产生的根本原因是，在 RC 隔离级别下，每条语句都会读取已提交事务的更新，若两次查询之间有其他事务提交，则会导致两次查询结果不一致。虽然如此，读提交隔离级别在生产环境中使用很广泛。 (3) 可重复读 (Repeatable Read, RR) 可重复读隔离级别解决了不可重复读的问题，但依然没有解决幻读的问题。那么不可重复读与幻读有什么区别呢？不可重复读重点在修改，即读取过的数据，两次读的值不一样；而幻读则侧重于记录数目变化【插入和删除】。一般教科书上告诉我们只有到串行化隔离级别才解决幻读问题，但mysql的innodb比较特殊，RR即解决了幻读问题，主要通过GAP锁实现。另外， 不是所有的数据库都实现了该隔离级别，后面会简单介绍下 mysql 是如何实现可重复读隔离级别的。 (4) 串行化 (Serializable) 在串行化隔离模式下，消除了脏读，幻象，但事务并发度急剧下降，事务的隔离级别与事务的并发度成反比

前言： 我一直想不到一个好的标题应该怎么写。我想MySQL的一些重要的内容。我在两次面试中都遇到过的，但直接用MySQL标题好像又不太贴切。干脆就是所写的内容吧。 MySQL事务： transaction Transactions are atomic units of work that can be committed or rolled back. When a transaction makes multiple changes to the database, either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back. Database transactions, as implemented by InnoDB , have properties that are collectively known by the acronym ACID, for atomicity, consistency, isolation, and durability. See Also ACID , commit , isolation level , lock , rollback

数据库事物隔离级别有四种，按照隔离性，由低到高依次是： Read Uncommitted 读未提交 Read Committed 读已提交 Repeatable Read 重复读(mysql默认事物) Serializable 可串行化 名词解释 读未提交:有一条插入sql，已入库，但未提交事物，能够查询到当前记录 读提交:有一条插入sql，已入库，但未提交事物，不能查询到当前记录，提交之后，才能查到 重复读:1.在session0中begin一个事物；2.在session1中插入一条数据（5），并commit; 3.在session0中查询，发现查询不到在session1中插入的数据～接下来，再做如下操作：1.在session0中commit; 2.在session0中再做查询操作，发现之前在session1中insert的5又可以查询到 可串行话:是最高的隔离级别，即在读取的每一行数据上会加锁，事物顺序执行。所以会出现锁超时等问题，在实际业务中很少使用 来源： CSDN 作者： 采坑先锋 链接： https://blog.csdn.net/qq_31564573/article/details/103648761

事务是一个工作单元，可能包含查询和修改数据以及修改数据定义等多个活动。我们可以显式或隐式的定义事务边界。可以使用BEGIN TRAN或者BEGIN TRANSACTION语句显式的定义事务的开始。如果希望提交事务，可以使用COMMIT TRAN语句显式的定义事务结束。如果不希望提交事务（即要撤销更改），可以使用ROLLBACK TRAN或者ROLLBACK TRANSACTION语句-摘抄自SQL Server 2012基础教程。 如果不显式的标记事务的边界，默认情况下，SQL Server将把每个单独语句作为一个事务，换句话说，默认情况下，每个单独语句结束后SQL Server自动提交事务。 说到事务就联想到并发，为了解决事务中的并发我们则不得不讨论下锁，所以接下来我们首先熟悉一下锁的模式-排他锁和共享锁。 先看看下面的试验，先开始一个事务处理，这个事务不提交也不回滚，然后另外在打开一个窗口查询数据。 在上面的事务没有提交也没有回滚的情况下，如果另一个程序在执行查询，那么就会阻塞，如果没有设置查询超时，就会一直等待。 原因：当事务会话对表进行修改（增删改）时，事务会请求数据资源的一个排他锁，这个锁直到事务完成（提交或者回滚）才会被取消。当读取数据时需要获取该资源上的共享锁，但是排他锁和共享锁不能兼容，此时会导致查询阻塞不得不进行等待。 就上面的试验，第一个事务拥有排它锁

一、什么是事务 　　事务是访问数据库的一个操作序列，数据库应用系统通过事务集来完成对数据库的存取。事务的正确执行使得数据库从一种状态转换成另一种状态。 　　事务必须服从ISO/IEC所制定的ACID原则。ACID是原子性（atomicity）、 一致性（consistency）、隔离性（isolation）和持久性（durability）的缩写事务必须服从ISO/IEC所制定的ACID原 则。ACID是原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）的缩 写。 原子性 。即不可分割性，事务要么全部被执行，要么就全部不被执行。如果事务的所有子事务全部提交成功，则所有的数据库操作被提交，数据库状态发生转换；如果有子事务失败，则其他子事务的数据库操作被回滚，即数据库回到事务执行前的状态，不会发生状态转换。 一致性或可串性 。事务的执行使得数据库从一种正确状态转换成另一种正确状态。 隔离性 。在事务正确提交之前，不允许把该事务对数据的任何改变提供给任何其他事务，即在事务正确提交之前，它可能的结果不应显示给任何其他事务。 持久性 。事务正确提交后，其结果将永久保存在数据库中，即使在事务提交后有了其他故障，事务的处理结果也会得到保存。 　　 　　运行嵌入式SQL应用程序或脚本，在可执行SQL语句第一次执行时

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 隔离级别为四种分别解决脏读，不可重复度，幻读等问题 脏读：指一个线程中的事务读取到了另外一个线程中未提交的数据。 不可重复读：一个事务对同一行数据重复读取两次，但是却得到了不同的结果。例如，在两次读取的中途，有另外一个事务对该型数据进行了修改，并提交。 幻读：一个线程事务读取到相关数据就一条，第二次读出现两条，新增的一条为另外一个线程事务提交插入的数据。 上图为各个隔离级别对应的问题 show variables like '%iso%'; 查看目前数据库的隔离级别 set @@session.tx_isolation = 'READ-COMMITTED'; --设置局部 set @@session.tx_isolation = 'REPEATABLE-READ'; 局 @@session 全 @@global 级联回滚(5.7.22后不会发生) 事务是需要手动提交和回滚的 来源： oschina 链接： https://my.oschina.net/u/3914215/blog/3145394

Transaction 也就是所谓的事务了，通俗理解就是一件事情。从小，父母就教育我们，做事情要有始有终，不能半途而废。 事务也是这样，不能做一半就不做了，要么做完，要么就不做。也就是说，事务必须是一个不可分割的整体，就像我们在化学课里学到的原子，原子是构成物质的最小单位。于是，人们就归纳出事务的第一个特性：原子性（Atomicity）。我靠，一点都不神秘嘛。 特别是在数据库领域，事务是一个非常重要的概念，除了原子性以外，它还有一个极其重要的特性，那就是：一致性（Consistency）。也就是说，执行完数据库操作后，数据不会被破坏。打个比方，如果从 A 账户转账到 B 账户，不可能因为 A 账户扣了钱，而 B 账户没有加钱吧。如果出现了这类事情，您一定会非常气愤，什么 diao 银行啊！ 当我们编写了一条 update 语句，提交到数据库的一刹那间，有可能别人也提交了一条 delete 语句到数据库中。也许我们都是对同一条记录进行操作，可以想象，如果不稍加控制，就会出大麻烦来。我们必须保证数据库操作之间是“隔离”的（线程之间有时也要做到隔离），彼此之间没有任何干扰。这就是：隔离性（Isolation）。要想真正的做到操作之间完全没有任何干扰是很难的，于是乎，每天上班打酱油的数据库专家们，开始动脑筋了，“我们要制定一个规范，让各个数据库厂商都支持我们的规范！”，这个规范就是