隔离级别

1.事务的特性 ACID 1.1原子性 事务中的操作，要么全部成功，要么全部失败；对于一个事务来说，不可能只执行其中的一部分操作 1.2一致性 数据库总是从一个一致性的状态转换到另一个一致性的状态 1.3隔离性 并发过程中，事务在最终提交之前是相互隔离的，不能相互干扰 1.4持续性 一旦事务提交，则其所做的修改不会永久保存到数据库 2事务并发产生的问题 2.1脏读 事务A第一次读取到price=100 同时事务B更新update price=120，但是此时的事务B还未commit 事务A读取的price=120 事务B->rollback操作 事务A读取到的是脏数据 2.2不可重复读 事务A第一次读取到price=100 同时事务B更新update price=120，并commit 事务A读取的price=120 事务A多次读取的结果不一致 2.3幻读 幻读和不可重复读的区别在于，幻读主要表现在数据的 删除 和 插入 ，而不可重复读表现在数据的 更新 事务A第一次读取到price=100 同时事务B更新delete price=100 这条记录，并commit 事务A读取的price=100 price这条记录已经不存在，但是事务A还是可以读取到 3数据库提供的解决方法 mysql提供了4种隔离级别 3.1read uncommitted 未提交读 2.1中 脏读 的场景

Spring——事务的特性、隔离机制（转） 一、事务 1.事务在项目开发中非常重要，涉及到数据一致性问题，不容马虎 2.事务的四大特性： 原子性：   原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。 一致性：   一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。   如：拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。 隔离性：   隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。 即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。 持久性 ：   持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。   例如：我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成

什么是事务 事务是应用程序中一系列严密的操作，所有的操作必须成功完成，否则每个操作中国所做的所有更改都会被撤销。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。 事务的结束有两种，当事务中的所有步骤全部成功执行时，事务提交。如果一个步骤失败，将发生回滚操作，撤销 之前到事务开始时的 所有操作。 事务的ACID 事务具有四个特征：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持续性（Durability）。这一个特性简称为ACID特性。 原子性：事务是数据库的逻辑工作单位，事务中包含的各操作要么都做、要么都不做。 一致性：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果是，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。 隔离性：一个事务的执行不被其他事务干扰。即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。 持续性：也称永久性，指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其他操作或者故障不应该对其执行结果有任何影响。

read-uncommitted（未提交读） 测试流程： 1、A设置read-uncommitted, start transaction 2、B执行start transaction，修改一条记录， 3、A查询记录，得到了以为正确的记录 4、B回滚。 问题：A读到了B没有提交的记录，也就是脏读。 read-committed（已提交读） 测试流程： 1、A设置read-committed, start transaction 2、B执行start transaction，修改一条记录，查询记录，记录已经修改成功 3、A查询记录，结果还是老的记录 4、B提交事务 5、A再次查询记录，结果是新的记录。 问题：解决了脏读的问题，但是出现一个新问题，A在一个事务中，两次读取的记录不一致，也就是不可重复读。 repeatable-read（可重复读） 测试流程： 1、A设置repeatable-read, start transaction，查询记录，结果是老的记录 2、B执行start transaction，修改一条记录，查询记录，记录已经修改成功 3、A查询记录，结果还是老的记录 4、B提交事务 5、A再次查询记录，结果还是老的记录。 问题：可以重复读，A在事务过程中，即使B修改了数据，并且commit，A读取的还是老的数据。实际上是A读取的数据还是事务开始时的快照。 注意

背景 当你手中抓住一件东西不放时，你只能拥有一件东西，如果你肯放手，你就有机会选择更多。与其在别人的生活里跑龙套，不如精彩做自己。人无所舍，必无所成。跌倒了，失去了，不要紧，爬起来继续风雨兼程，且歌且行。 一、概念 事务到底是什么东西呢？想必大家学习的时候也是对事务的概念很模糊的。接下来通过一个经典例子讲解事务。 银行在两个账户之间转账，从A账户转入B账户1000元，系统先减少A账户的1000元，然后再为B账号增加1000元。如果全部执行成功，数据库处于一致性；如果仅执行完A账户金额的修改，而没有增加B账户的金额，则数据库就处于不一致状态，这时就需要取消前面的操作。这过程中会有一系列的操作，比如余额查询，余额做加减法，更新余额等，这些操作必须保证是一个整体执行，要么全部成功，要么全部失败，不能让A账户钱扣了，但是中途某些操作失败了，导致B账户更新余额失败。这样用户就不乐意了，银行这不是坑我吗？因此简单来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在MySQL中，事务支持是在引擎层实现的。你现在知道，MySQL是一个支持多引擎的系统，但并不是所有的引擎都支持事务。比如MySQL原生的MyISAM引擎就不支持事务，这也是MyISAM被InnoDB取代的重要原因之一。 接下来会以InnoDB为例，抽丝剥茧MySQL在事务支持方面的特定实现。 二、隔离性与隔离级别

READ-UNCOMMITED（读未提交） 事务A能读到事务B未提交的数据，也就有了脏读，这个事务隔离级别会发生 脏读、不可重复读、幻读 。 READ-COMMITED（读已提交） 事务只能看到已经提交的数据，事务再提交前的操作对其他事务是不可见的。 这个级别可能会出现 不可重复读 ，事务A先读到了c，但是在事务A提交前，事务B修改了c并且提交了，事务A再读就和原来的不一样了，重复读的结果不一样，还可能出现 幻读 。 REPEATABLE READ（可重复读） 同一事务中多次读取同样的记录的结果是一样的，这个MySQL默认的隔离级别。 可能出现 幻读 ，比如事务A读取了某个范围内的记录，事务B再这个范围内插入了新的记录，那么A再次读取的时候就出现了幻行。 在MySQL的InnoDB和XtraDB中通过MVCC解决了幻读。 SERIALIZABEL（可串行化） 强制事务串行执行，避免了前面所有的问题，可能会导致大量超时和锁竞争的问题。 MVCC（多版本并发控制） InnoDB是通过每行后面保存 两个隐藏的列 来实现的，分别保存 行的创建时间和过期时间 ，保存时时系统版本号，没开始一个新的事务都会递增这个版本号。 在可重复读下的MVCC： SELECT： 1）InnoDB只查找早于当前事务版本的数据行，也就是行的系统版本号要小于等于事务的系统版本号

Spring事务的基本原理 Spring事务的本质其实就是数据库对事务的支持，没有数据库的事务支持，spring是无法提供事务功能的。对于纯JDBC操作数据库，想要用到事务，可以按照以下步骤进行： 获取连接 Connection con = DriverManager.getConnection() 开启事务con.setAutoCommit(true/false); 执行CRUD 提交事务/回滚事务 con.commit() / con.rollback(); 关闭连接 conn.close(); 使用Spring的事务管理功能后，我们可以不再写步骤 2 和 4 的代码，而是由Spirng 自动完成。那么Spring是如何在我们书写的 CRUD 之前和之后开启事务和关闭事务的呢？解决这个问题，也就可以从整体上理解Spring的事务管理实现原理了。下面简单地介绍下，注解方式为例子 配置文件开启注解驱动，在相关的类和方法上通过注解@Transactional标识。 spring 在启动的时候会去解析生成相关的bean，这时候会查看拥有相关注解的类和方法，并且为这些类和方法生成代理，并根据@Transaction的相关参数进行相关配置注入，这样就在代理中为我们把相关的事务处理掉了（开启正常提交事务，异常回滚事务）。 真正的数据库层的事务提交和回滚是通过binlog或者redo

关系型数据库的隔离级别有四种：读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）和序列化（Serializable） 多事务并发执行常见的问题：脏读、幻读、不可重复读 脏读：事务1更新了数据，但没有提交；事务2读取了更新后的数据。然后事务1回滚了，事务2读取到的数据是无效的。 幻读：事务1读取数据时事务2增加了一条记录并提交，事务1再次读取时可以读取到事务2新增的那一条记录。或者可以这样说，幻读是指在同一个事务的两次查询（同一范围）中，后一次查询读取到了前一次查询没有读取到的数据。更通俗点说，事务1第一次读取还没有那条记录，第二次读取却有了那条记录，是不是跟见鬼了一样？难道第一次是幻觉？ 不可重复读：事务1读取记录时，事务2更新了记录并提交，事务1再次读取时可以看到事务2修改后的记录。通俗点说：事务1第一次读到的数据是这样的，第二次读到的却是那样的...... 幻读和不可重复读：不可重复读重点在于update和delete，而幻读的重点在于insert。 读未提交：事务中修改的数据，即便该事务还未提交，其他事务也可以读取到。可能会因此出现脏读、幻读和不可重复读。 读已提交：事务中修改的数据，只能等事务提交后才能够被读取到。可能会因此产生不可重复读和幻读。 可重复读：事务开始读数据的时候

F查询 　　 Django 提供 F() 来做这样的比较。F() 的实例可以在查询中引用字段，来比较同一个 model 实例中两个不同字段的值 　　 示例1： 查询出卖出数大于库存数的商品 from django.db.models import F ret1=models.Product.objects.filter(maichu__gt=F('kucun')) print(ret1) F可以帮我们取到表中某个字段对应的值来当作我的筛选条件，而不是我认为自定义常量的条件了，实现了动态比较的效果 Django 支持 F() 对象之间以及 F() 对象和常数之间的加减乘除和取模的操作。基于此可以对表中的数值类型进行数学运算 将每个商品的价格提高50块 models.Product.objects.update(price=F('price')+50) 引申： 如果要修改char字段咋办(千万不能用上面对数值类型的操作！！！)？ 如：把所有书名后面加上'新款',(这个时候需要对字符串进行拼接Concat操作，并且要加上拼接值Value) from django.db.models.functions import Concat from django.db.models import Value ret3=models.Product.objects.update(name

级别： 中级 齐克科 ( qikeke@cn.ibm.com ), 软件工程师, IBM Elaine Zhan ( ezhan@cn.ibm.com ), 软件咨询工程师, IBM 陈荔龙 ( chenlil@cn.ibm.com ), 软件工程师, IBM 2008 年 5 月 08 日 本文介绍一种数据库并发机制表格分析方法。借助表格，能够帮助理解、分析 DB2 的并发机制，并能对 DB2如何实现这种并发机制窥探一二。我们还将借助一些实例，来进行概念的验证和对理论更加深刻的理解。 基本概念 对于数据库初学者来说，深刻理解 DB2 里面的并发机制并不是一件很容易的事。事务、隔离级别、锁、锁兼容这些概念读起来十分晦涩，这些概念之间的关系似乎也是若隐若现，令人琢磨不透。 这里我们无意把所有的数据库并发机制相关概念再复述一遍，这不是本文的重点，但是很有必要在这里对一些重要的概念稍微复习一下，包括事务，隔离级别，锁，锁兼容等。对这些概念有大概的了解会对您阅读本文大有帮助。 事务 事 务在 DB2 中通常称为工作单元。工作单元是应用程序进程内可恢复的操作序列。数据库管理器使用它来确保数据库处于一致状态。对数据库的任何读取或写入都在一个工作单 元内执行。当对数据库发出第一条 SQL 语句时，就隐式启动了一个工作单元。由同一应用程序执行的所有后续读写操作被认为是同一工作单元的一部分