事务回滚

原文作者：VectorJin https://juejin.im/post/5e066c9ff265da33b0718f89 1. 本地事务 　　事务Transaction由一组SQL组成，具有四个ACID特性 1.1 ACID Atomicity 原子性 构成事务的一组SQL，要么全部生效，要么全不生效，不会出现部分生效的情况 Consistency 一致性 数据库经过事务操作后从一种状态转变为另一个状态。可以说原子性是从行为上描述，而一致性是从结果上描述 isolation 隔离性 事务操作的数据对象 相对于 其他事务操作的数据对象相互隔离，互不影响 durability 持久性 事务提交后，其结果就是永久性的，即使发生宕机（非磁盘损坏） 1.2 事务实现 　　对于MySQL数据库（InnoDB存储引擎）而言，隔离性是通过不同粒度的锁机制来实现事务间的隔离；原子性、一致性和持久性通过redo log 重做日志和undo log回滚日志来保证的。 　　 redo log： 当数据库对数据做修改的时候，需要把数据页从磁盘读到buffer pool中，然后在buffer pool中进行修改，那么这个时候buffer pool中的数据页就与磁盘上的数据页内容不一致，称buffer pool的数据页为dirty page 脏数据，如果这个时候发生非正常的DB服务重启

using (TransactionScope trans = new TransactionScope()) { try { InsertUserBase(); //它插入不成功，自己回滚 UserInfos userInfo = new UserInfos { UserID = "1", RealName = "zzl", }; db.UserInfos.InsertOnSubmit(userInfo); db.SubmitChanges(); trans.Complete(); } catch (Exception) { // throw; } finally { trans.Dispose(); } } #endregion static bool InsertUserBase() { bool flag; try { UserBases userbase = new UserBases { UserID = "0005", Name = "zzl", CreateDate = DateTime.Now, UpdateDate = DateTime.Now, }; db.UserBases.InsertOnSubmit(userbase); db.SubmitChanges(); flag = true; } catch (Exception) { throw; }

MySQL索引与事务详解 一、前言 ​ 上一章我们讲解了MySQL的手工编译安装流程以及相关的数据库操作命令（sql语句），本文将要详细介绍MySQL索引与事务的概念及原理，并初步了解MySQL数据库视图概念，简述数据库的存储过程。 二、索引 2.1索引的概念——什么是索引? ​ 一般来说，一篇论文，或者说一本书，都有其目录，而目录一般是所有章节的概述，或者说是要点核心，而索引的概念其实也与之类似。 ​ 索引，顾名思义，就是一个方便用户搜索所需资源的引导，只不过在数据库中，索引一般被认为是一种特殊的文件，尤其在Linux系统中（"一切皆文件"）。从专业术语上解释其含义就是“代表记录的引用指针”。 2.2索引的作用 加快查询速度，提高工作效率； 降低i/o成本，提供基础排序； 加快多表之间的连接； 支持唯一性索引（下面会介绍什么是唯一性索引），保证数据表中数据的唯一性性； 2.3索引的分类 2.3.1普通索引 ​ 就是一般的索引，只是为了区别于其他特殊索引的一个统称 2.3.2唯一性索引 ​ 与普通索引基本类同，区别在于，唯一性索引的列中的所有值都不相同，即“唯一”。 ​ 简单举例来说，学生数据表，年龄可以是普通索引，但不可以是唯一性索引，但是详细住址可以是。 2.3.3主键索引 ​ 本质上也是一种唯一性索引，但必须指定为“primary key”，该索引要求主键中的每个值都唯一

本文概要 本文分两部分， 第一部分概念介绍，重在理解。 第二部分通过MySQL Innodb中的具体实现，加深相关知识的印象。 本文的原意是一篇个人学习笔记，为了避免成为草草记录一下的流水账，尝试从给人介绍的角度开写。但在整理的过程中，越来越感觉力不从心，一是细节太多了，原以为足够了解的一个小知识点下可能隐藏了很多细节；二是内容与范围的取舍，既想有点技术性避免空谈，又不想陷入枯燥冗长的小细节描述。几番折腾，目前的想法把坑填上，能写完就不错了，你读起来有不顺或错误的地方请见谅，欢迎反馈。 1. 概念与理解 Redo与undo并非是相互的逆操作，而是能配合起来使用的两种机制。 说是两种机制，其实都是日志记录，不同的是redo记录以顺序附加的形式记录新值，如某条记录<T,X,V>，表示事物T将新值V存储到 数据库 元素X，新值可以保证重做； 而Undo记录通常以随机操作的形式记录旧值，如某条记录<T1,Y,9>，表示事物T1对Y进行了修改，修改前Y的值是9，旧值能用于撤销，也能供其他事务读取。 Redo用来保证事务的原子性和持久性，Undo能保证事务的一致性，两者也是系统恢复的基础前提。 1.1 Redo 一个事务从开始到结束，要么提交完成，要么中止，具有原子性。而反映在redo日志中可能需要若干条记录来保证，如： <T0 start> <T0,A,500> <T0,B,500> <T0

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 聊一个数据库脚本的版本工具 Liquibase， 官网在这里 ，初次看到，挺神奇的，数据库脚本也可以有版本管理，同类型的工具还有 flyway 。 开发过程经常会有表结构和变更，让运维来维护的话，通常会有很大的沟通成本，有时在开发方案有问题的时候，提测失败整个项目需要回滚，代码回滚起来是很容易的，通常有备份，但数据库的话就要人工来逐行分析并写出回滚语句，Liquibase 这时候就有用了。 Liquibase 适用场景感觉不多，所以可能有人没听过它的名头； 首先这种自动执行的家伙肯定是不适合于生产环境的，然后在数据量大的时候是不可能用数据库自带的 alter 语句的，一般都是手动创建另一张表，然后用 sql 语句将数据批量复制过去，再者使用容器化也比它好，个人觉得它一般用于开发和测试环境，比较厉害的一个功能是可以比较两个库的差异然后生成补丁包，上线时可以这么玩。 这篇文章 说得不错，我是在这篇基本上写的 核心概念 首先它是用于管理数据库版本的，所以就会有这些概念：版本号，管理的数据，差异比较，版本回滚 它的版本号由开发人员来维护，使用 author + id 管理的数据最小单元为 changeSet ，这个 changeSet 看官网说是可以用 xml,yaml,json,sql 来编写 提交数据，比较差异

摘自： https://www.cnblogs.com/iceggboom/p/12144570.html 分布式事务框架-seata初识 一、事务与分布式事务 事务,在数据库中指的是操作数据库的最小单位,往大了看,事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。 那为什么会有分布式事务呢?单机事务是通过将操作限制在一个会话内通过数据库本身的锁以及日志来实现ACID.因为引入了分布式架构,所以事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上.简单说就是多各数据库之间无法保证保证各自的操作同时成功或同时失败。 二、介绍 Seata:Simple Extensible Autonomous Transaction Architecture，简易可扩展的自治式分布式事务管理框架，其前身是fescar。阿里巴巴GTS的开源版实现，是一种分布式事务的解决方案。 三、架构 Coordinator Core：最下面的模块是事务协调器核心代码，主要用来处理事务协调的逻辑，如是否 Commit、Rollback 等协调活动。 Store：存储模块，用来将我们的数据持久化，防止重启或者宕机数据丢失。 Discover：服务注册/发现模块，用于将 Server 地址暴露给 Client。 Config

一、Propagation （事务的传播属性） Propagation ：　　key属性确定代理应该给哪个方法增加事务行为。这样的属性最重要的部份是传播行为。有以下选项可供使用：PROPAGATION_REQUIRED--支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。 PROPAGATION_SUPPORTS--支持当前事务，如果当前没有事务，就以非事务方式执行。 PROPAGATION_MANDATORY--支持当前事务，如果当前没有事务，就抛出异常。 PROPAGATION_REQUIRES_NEW--新建事务，如果当前存在事务，把当前事务挂起。 PROPAGATION_NOT_SUPPORTED--以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 PROPAGATION_NEVER--以非事务方式执行，如果当前存在事务，则抛出异常。 1： PROPAGATION_REQUIRED 加入当前正要执行的事务不在另外一个事务里，那么就起一个新的事务 比如说，ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于执行ServiceA.methodA的时候， ServiceA.methodA已经起了事务，这时调用ServiceB.methodB，ServiceB.methodB看到自己已经运行在ServiceA

1.spring,mybatis事务管理配置与@Transactional注解使用： 概述 事务管理对于企业应用来说是至关重要的，即使出现异常情况，它也可以保证数据的一致性。 Spring Framework对事务管理提供了一致的抽象，其特点如下： 为不同的事务API提供一致的编程模型，比如JTA(Java Transaction API), JDBC, Hibernate, JPA(Java Persistence API和JDO(Java Data Objects) 支持声明式事务管理，特别是基于注解的声明式事务管理，简单易用 提供比其他事务API如JTA更简单的编程式事务管理API 与spring数据访问抽象的完美集成 事务管理方式 spring支持编程式事务管理和声明式事务管理两种方式。 编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。 声明式事务管理建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码

Spring支持七种传播属性（Propagration）： 1、PROPAGATION_REQUIRED　　--支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。 2、PROPAGATION_SUPPORTS　　--支持当前事务，如果当前没有事务，就以非事务方式执行。 3、PROPAGATION_MANDATORY　　--支持当前事务，如果当前没有事务，就抛出异常。 4、PROPAGATION_REQUIRES_NEW　　--新建事务，如果当前存在事务，把当前事务挂起。 5、PROPAGATION_NOT_SUPPORTED　　--以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 6、PROPAGATION_NEVER　　--以非事务方式执行，如果当前存在事务，则抛出异常。 7、PROPAGATION_NESTED　　--如果一个活动的事务存在，则运行在一个嵌套的事务中；如果没有活动事务, 则按PROPAGATION_REQUIRED 属性执行。 具体解释如下： 1： PROPAGATION_REQUIRED 　　加入当前正要执行的事务不在另外一个事务里，那么就起一个新的事务。 　　比如说，ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于执行ServiceA.methodA的时候，ServiceA

传播行为 事务的第一个方面是传播行为。传播行为定义关于客户端和被调用方法的事务边界。Spring定义了7中传播行为。 传播行为 意义 PROPAGATION_MANDATORY [ propagation_manadatory ] 表示该方法 必须运行 在一个事务中。如果当前没有事务正在发生，将 抛出一个异常 PROPAGATION_NESTED [ propagation_nested ] 表示如果当前正有一个事务在进行中，则该方法应当运行在一个 嵌套式事务 中。被嵌套的事务可以独立于封装事务进行提交或回滚。如果封装事务不存在，行为就像PROPAGATION_REQUIRES一样。 PROPAGATION_NEVER [ propagation_never ] 表示当前的方法 不应该在一个事务中运行 。如果一个事务正在进行，则会 抛出一个异常 。 PROPAGATION_NOT_SUPPORTED [ propagation_not_supported ] 表示该方法 不应该 在一个事务中运行。如果一个现有事务正在进行中，它将在该方法的运行期间 被挂起 。 PROPAGATION_SUPPORTS [ propagation_supports ] 表示当前方法 不需要 事务性上下文，但是如果有一个事务已经在运行的话，它也可以在这个事务里运行。 PROPAGATION