隔离级别

数据库事务并发带来的问题如下： A.丢失更新：撤销一个事务时，把其他事务已提交的更新数据覆盖（A和B事务并发执行，A事务执行更新后，提交；B事务在A事务更新后，B事务结束前也做了对该行数据的更新操作，然后回滚，则两次更新操作都丢失了）。 B.脏读：一个事务读到另一个事务未提交的更新数据（A和B事务并发执行，B事务执行更新后，A事务查询B事务没有提交的数据，B事务回滚，则A事务得到的数据不是 数据库 中的真实数据。也就是脏数据，即和数据库中不一致的数据）。 C.不可重复读：一个事务读到另一个事务已提交的更新数据（A和B事务并发执行，A事务查询数据，然后B事务更新该数据，A再次查询该数据时，发现该数据变化了）。 D. 覆盖更新：这是不可重复读中的特例，一个事务覆盖另一个事务已提交的更新数据（即A事务更新数据，然后B事务更新该数据，A事务查询发现自己更新的数据变了）。 E.幻读：一个事务读到另一个事务已提交的新插入的数据（A和B事务并发执行，A事务查询数据，B事务插入或者删除数据，A事务再次查询发现结果集中有以前没有的数据或者以前有的数据消失了）。 为此数据库系统提供了四种事务隔离级别供用户选择： A.Serializable（串行化）：一个事务在执行过程中完全看不到其他事务对数据库所做的更新（事务执行的时候不允许别的事务并发执行。事务串行化执行，事务只能一个接着一个地执行

再次之前自认为我对数据库事务和隔离级别很熟悉了，至少以前整理过，看过网上很多文章，有些带有命令行操作的印象挺深，但是事务传播（包块调用外部系统服务）、分布式锁、mybatis一级缓存等一起存在业务代码中，导致了很多看起来听不可思议的问题，这都是线上案例。 项目中架构师是否跟你说类似的话，事务最好不要嵌套,为什么？如果这样的话事务传播应如何使用，为了方便本片先将事务相关的基础知识做下汇总： 数据库事务ACID特性 1）原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。 2）一致性（Consistency）事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。 3） 隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账（其实是隔离级别中的串行化）。 4）持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。 事务4种隔离级别 1):Read Uncommitted

CREATE TABLE `users` ( `id` smallint ( 6 ) NOT NULL AUTO_INCREMENT, `name` varchar ( 25 ) DEFAULT NULL , `age` tinyint( 4 ) DEFAULT NULL , PRIMARY KEY ( `id` ) ) ENGINE=InnoDB AUTO_INCREMENT= 11 DEFAULT CHARSET=utf8; ALTER table `users` auto_increment= 1 ; INSERT INTO users( `name` , `age` ) VALUES ( 'lyf_16' , 16 ); INSERT INTO users( `name` , `age` ) VALUES ( 'xtf_17' , 17 ); 当前事务(currTx)SQL 当前事务(currTx)结果 其他事务(otherTx)SQL 其他事务(otherTx)结果 SELECT @@GLOBAL.TX_ISOLATION AS 'GLOBAL-tx',@@SESSION.TX_ISOLATION AS '@@SESSION-tx'; SELECT @@GLOBAL.TX_ISOLATION AS 'GLOBAL-tx',@@SESSION.TX_ISOLATION AS

mysql事务的隔离级别 查看当前数据库的隔离级别： select @@tx_isolation; 默认的隔离级别为：可重复度(REPEATABLE-READ) 设置当前会话的隔离级别： set tx_isolation='<隔离级别>' 读未提交----read-uncommitted 当多个会话同时操作同一张表，其中某一个会话M尝试去读取表中的数据时，它会直接读取到其他会话开启事务后对表的内容造成修改后的但事务尚未提交的内容。当事务发生回滚，会话M再去查询，会出现与此之前不同的数据，造成脏读。 会话A开启事务，往表中修改了数据，但事务还未结束。此时会话B想要查询这个表的数据，查到的内容是刚刚会话A修改后的内容。若会话A在会话B刚刚查询之后选择回滚了事务，会话B再去查询，会跟之前查询到的内容不一样。 读已提交----read-committed 跟上面的读未提交的相反，当前的会话只会读到其他会话结束后的表数据，无论其他会话在自己的事务中做了啥修改，只要为结束当前的会话，其他的会话都无法读取到会话未结束前的修改。 可重复读----repeatable-read 会话M开始事务去查询的同时，其他多个会话在对会话M查询的内容做修改，无论其他会话结束与否，会话M的事务只要没有结束，会话M去查询的内容始终与会话M开启事务时查询到的内容一致。当会话M的事务结束后，会话M再去查询

数据库事务ACID特性 　　数据库事务正确执行的4个基础要素是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。 　　这里的原子性、一致性和持久性都比较好理解，而隔离性就不一样了，它涉及了多个事务并发的状态。首先多个事务并发会产生数据库丢失更新的问题，其次隔离性又分为多个层级。 隔离级别 　　 脏读 是最低的隔离级别，其含义是允许一个事务去读取另一个事务中未提交的数据。以丢失更新的消费为例进行说明，如表所示。 　　为了克服脏读，SQL标注提出了第二个隔离级别―― 读/写提交 。所谓读/写提交，就是说一个事务只能读取另一个事务已经提交的数据。依旧以丢失更新的夫妻消费为例，如表所示。 不可重复读 　　为了克服不可重复读带来的错误，SQL标准又提出了一个 可重复读 的隔离级别来解决问题。注意，可重复读这个概念是针对数据库同一条记录而言的，换句话说，可重复读会使得同一条数据库记录的读/写按照一个序列化进行操作，不会产生交叉情况，这样就能保证同一条数据的一致性，进而保证上述场景的正确性。但是由于数据库并不是只能针对一条数据进行读/写操作，在很多场景，数据库需要同时对多条记录进行读/写，这个时候就会产生下面的情况，如表所示。 　　为了克服幻读，SQL标准又提出了 序列化 的隔离级别。它是一种让SQL按照顺序读/写的方式

本篇内容 什么是事务，它有什么用？ 事务的几个特性 事务常见操作指令详解 事务的隔离级别详解 脏读、不可重复读、可重复读、幻读详解 演示各种隔离级别产生的现象 关于隔离级别的选择 一、什么是事务？ 　　 数据库中的事务是指对数据库执行一批操作，这些操作最终要么全部执行成功，要么全部失败，不会存在部分成功的情况。 二、事务的几个特性(ACID)　　 　　原子性(Atomicity) 　　事务的整个过程如原子操作一样，最终要么全部成功，或者全部失败，这个原子性是从最终结果来看的，从最终结果来看这个过程是不可分割的。 　　一致性(Consistency) 　　事务开始之前、执行中、执行完毕，这些时间点，多个人去观察事务操作的数据的时候，看到的数据都是一致的，比如在事务操作过程中，A连接看到的是100，那么B此时也去看的时候也是100，不会说AB看到的数据不一样，他们在某个时间点看到的数据是一致的。 　　隔离性(Isolation) 　　一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。 　　持久性(Durability) 　　一个事务一旦提交，他对数据库中数据的改变就应该是永久性的。当事务提交之后，数据会持久化到硬盘，修改是永久性的。 三、Mysql中事务操作　　 　　mysql中事务默认是隐式事务

事务命令 事务指逻辑上的一组操作，组成这组操作的各个单元，要不全部成功，要不全部不成功。 转账实例： 1 2 UPDATE account set balance=balance-5000 WHERE name =”yuan”; UPDATE account set balance=balance+5000 WHERE name =”xialv”; create table test2(id int PRIMARY KEY auto_increment,name VARCHAR(20)) engine=innodb; INSERT INTO test2(name) VALUE ("alvin"), ("yuan"), ("xialv"); start transaction; insert into test2 (name)values('silv'); select * from test2; commit; -- 保留点 start transaction; insert into test2 (name)values('wu'); savepoint insert_wu; select * from test2; delete from test2 where id=4; savepoint delete1; select * from test2; delete from

事务的基本要素（ACID）有四个，分别是原子性，一致性，隔离性和持久性。 原子性和持久性很好理解，一致性是指事务执行过程中的状态对外是不可见的，要么是执行前的状态，要么是执行后的状态，执行前是一个一致的状态，执行后是另外一个一致性状态。比如银行卡a向银行卡b转账，转账这个事务中有两个操作：将钱从卡a转出，将钱转到卡b。转账事务执行之前状态是一致的，转账事务执行了第一个操作之后，状态是不一致的，此时a卡上的钱少了，但b卡上的钱没有增加，状态是不一致的。执行完第二个操作，即将钱转到b卡上后，才具备正确的逻辑意义，此时的状态又是一致的了。 事务的隔离性指并发事务之间互相影响的程度，实质上并发事务互不影响才是事务隔离性的要求。但是为了提高并发，不得不做出一些妥协，所以又将事务的隔离性从低到高分为四个级别。 1.1 Read Uncommitted 读未提交，最低的隔离级别，在此级别上一个事务可以读到另一个事务未提交的结果。因此会出现脏读问题，读到的数据是一个临时的，不正确的数据。 1.2 Read Committed 读已提交，相对于读未提交来说的，指只有当事务提交之后，其更新结果才可以被其他事务看到。可以解决脏读问题，但是会存在另外的问题：不可重复读。例如事务a在事务b多次读取过程中提交了更新，此时事务b读到的结果是不一致的。 1.3 Repeated Read 可重复读，指在一个事务中

最近在写代码调试时，遇到了一个问题。 具体操作如下： 1.调用方法A，并且方法A加上了@Transactional事务注解。 2.在方法A内部，查询并更新某个字段F的值。 3.处理其他逻辑。 4.查询并打印日志，记录关键字段的值，包括字段F。 5.方法A结束。 由于刚刚接手这块代码，而且这个方法又写得很长，所以很多逻辑都没法细看，只能慢慢调试。 我在第4步打了断点，调试时查看日志，感觉数据有问题，将sql复制到数据库里面手动跑了一遍， 发现 在方法里和数据库里，执行同一条Sql，结果竟然不一样。 一开始还有点蒙圈，以为是IDE的bug，可能是缓存之类的问题。 然后又调试了几遍，单步调试时观察到 手动在数据库里查出来的字段值，总是方法刚开始还未变更时的值 。 恍然才明白，原来是事务隔离级别造成的。 这些知识点，其实以前面试都背得滚瓜烂熟。现在时间久了，一下子又忘光了。 Q:数据库的隔离级别有哪些？ 读未提交（read-uncommitted）读提交（read-committed） 可重复读（repeatable-read）串行化（serializable）。 Q:mysql默认的数据库隔离级别是什么？ 可重复读（repeatable-read） Mysql采用INNODB存储引擎。SELECT操作，使用一致性非锁定读。 在READ COMMITTED事务隔离级别下，对于快照数据

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隔离级别命令： 修改全局隔离级别为读提交：