mysql事务

前言 先介绍一下事务的概念 事务（Transaction） 就是数据库管理的一个逻辑单位，由一个有效的数据库操作序列构成。 事物ACID特性 原子性（Atomicity）：事务作为一个整体被执行，要么全部成功执行，要么全部失败 一致性（Consistency）：指的是逻辑上的一致性，即所有操作是符合现实当中的期望的 隔离性（Isolation）：多个事务并发时，一个事务不应该影响其他事务的执行 持久性（Durability）：被提交过的事务对数据库的修改应该永久保存在数据库中 通俗的理解，就是将一系列的数据库操作（增删改查）看做一个整体，要么所有操作都成功，要么都失败。 一、产生的问题 如果没有事务隔离的话，会发生以下的问题 1. 脏读 脏读 是指一个事务读取了另一个事务未提交的数据 2. 不可重复读 不可重复读 是指事务中多次读取，数据改变。 不可重复读和脏读的区别：不可重复读是事务A读取某行数据后，事务B插入了一行新数据并提交之后，事务A再去读数据，读到了修改后的数据集。 3. 幻读 幻读 是指事务多次读取，结果集数量改变。 上面还有点不清晰，借鉴一下别人的白话解释 幻读，并不是说两次读取获取的结果集不同，幻读侧重的方面是某一次的 select 操作得到的结果所表征的数据状态无法支撑后续的业务操作。更为具体一些：select 某记录是否存在，不存在，准备插入此记录，但执行

mark下自己近期在电商开发中遇到的一个问题－数据库死锁及其排查过程。 先抛一个业务报错日志做为这次梳理的开始 上图是我接收到的错误报警，SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction，错误信息显示我们业务中有一条数据库操作遇到了死锁情况。接下来就开始我们的追查之旅。 1.执行“show engine innodb status”获取INNODB引擎当前信息（ show engine innodb status 详细介绍 ） ------------------------ LATEST DETECTED DEADLOCK ------------------------ 2017-01-04 09:25:17 7f553477d700 *** (1) TRANSACTION: TRANSACTION 124378994, ACTIVE 0.007 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 4 lock struct(s), heap size 1184, 8 row lock(s), undo log entries

1.1 未提交读 未提交读(READ_UNCOMMITTED)是最低的隔离级别，其含义是允许一个事物读取另一个事物没提交的数据。优点在于并发能力高，适合那些对数据一致性没有要求而追求高并发的场景，最大缺点是出现脏读。 @Transactional(isolation = Isolation.READ_UNCOMMITTED) 例子讲解： T3时刻，因为采用未提交读，所以事务2可以读取事务1未提交的库存数据为1,这里当它扣减库存后则数据为0，然后它提交了事务，库存就变为了0 。，而事务1在T5时刻回滚事务，因为第一类丢失更新已经被克服，所以它不会将库存回滚到2，那么最后的结果就变为了0，这样就出现了错误。 1.2 读写提交 读写提交(READ_COMMITTED)，一个事务只能读取另外一个事务已提交的数据，不能读取未提交的数据。该级别克服了脏读，但不可重复读。 @Transactional(isolation = Isolation.READ_COMMITTED) 案例讲解: 1.3 可重复读 可重复读(REPEATABLE_READ)，目标是克服读写提交中出现的不可重复读的现象，但会出现幻读。 1 @Transactional(isolation = Isolation.REPEATABLE_READ) 案例讲解： 1.4 串行化 串行化(SERIALIZABLE)

//相当于开启事务 //当我们execute的时候，就和服务端建立链接 　　 dataSource.getConnection().createStatement(); //事务的回滚 dataSource.getConnection().rollback(); //默认的话是自动提交，所有的事务操作框架都会把autoCommit改成false，否则的话无法手动干预 dataSource.getConnection().setAutoCommit(false); //只读事务 dataSource.getConnection().setReadOnly(true); //事务的提交 dataSource.getConnection().commit(); 1、数据库操作，都会通过事务来管理 ACID，最大的问题，解决数据一致性的问题，能量守恒 分布式：分布式事务处理瞬时一致性，通常说的是最终的一致性（异步核对，主流的方式就通过日志） 事务的操作流程：事务只是一种思想，该如何用技术实现 像一般操作的Connection（接口）类，这个类是java客户端和数据库事务通信的桥梁，也就是一个包装类，就是一个TCP链接，底层就是socket 但java自己不实现，只是提供这个封装，提供这个JDK，让其他相关数据库厂商自己实现，所以我们要单独导入类似Mysql的jar包

事务的概念 事务是一种机制、一个操作序列，包含了一组数据库操作命令，并且把所有命令作为一个整体一起向系统提交或撤销操作请求，即这一组数据库命令要么都执行，要么都不执行。 事务是一个不可分割的工作巡逻单元，在数据库系统上执行并发操作时，事务时最小的控制单元 适用于多用户同时操作的数据库系统的场景，如银行、保险公司及证券公司交易系统等等 通过事务的整体性以保证数据的一致性 事务的ACID特点 原子性（Atomicity） 事务是一个完整的操作，事务的各元素是不可分的（原子的） 事务中的所有元素必须作为一个整体提交或回滚 如果事务中的任何元素失败，则整个事务将失败 一致性（Consistency） 当事务完成时，数据必须处于一致状态：在事务开始之前，数据库中存储的数据处于一致状态；在正在进行的事务时，数据可能处于不一致的状态；当事务成功完成时，数据必须再次回到已知的一致状态 隔离性（Isolation） 对数据进行修改的所有并发事务是彼此隔离的，这表明事务必须是独立的，它不应以任何方式依赖于或影响其他事务 修改数据的事务可以在另一个使用相同数据的事务开始之前访问这些数据，或者在另一个使用相同数据的事务结束之后访问这些数据 持久性（Durability 事务持久性不管系统是否发生故障，事务处理的结果都是永久的 一旦事务被提交，事务的效果被永久地保留在数据库中 事务的操作

数据事务四种隔离机制和七种传播行为 一、隔离级别： 数据库事务的隔离级别有4个，由低到高依次为 Read uncommitted、 Read committed、 Repeatable read、 Serializable，这四个级别可以逐个解决 脏读、 不可重复读、 幻读这几类问题。 １. ISOLATION_READ_UNCOMMITTED：这是事务最低的隔离级别，它充许令外一个事务可以看到这个事务未提交的数据。 这种隔离级别会产生脏读，不可重复读和幻像读。 ２. ISOLATION_READ_COMMITTED：保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据 ３. ISOLATION_REPEATABLE_READ：这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。 它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。 ４. ISOLATION_SERIALIZABLE：这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。 除了防止脏读，不可重复读外，还避免了幻像读。 我们使用 test 数据库，新建 tx 表：－－－ＭｙＳＱＬ数据库 第1级别：Read Uncommitted(读取未提交内容) (1)所有事务都可以看到其他未提交事务的执行结果 (2

MySQL数据库为我们提供的四种隔离级别：(依次解决脏读、不可重复读、幻读） 　　① Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。 　　② Repeatable read (可重复读)：可避免脏读、不可重复读的发生。（Mysql默认的方式） 　　③ Read committed (读已提交)：可避免脏读的发生。（Oracle默认的方式） 　　④ Read uncommitted (读未提交)：最低级别，任何情况都无法保证。（INNODB内部机制） 数据库事务正常执行的四个特性： ACID属性： 原子性（atomicity）：即不可分割，事务要么全部被执行，要么全部不执行 一致性（consistency）：事务的执行使得数据库从一种正确状态转换成另外一种正确状态 隔离性（isolation）：在事务正确提交之前，不允许把事务对该数据的改变提供给任何其他事务 持久性（durability）：事务正确提交之后，其结果将永远保存在数据库之中，即使在事务提交之后有了其他故障，事务的处理结果也会得到保存 并发下事务产生的问题： 1、脏读：事务A读到了事务B还没有提交的数据； 2、不可重复读：在一个事务里面读取了两次某个数据，读出来的数据不一致； 3、幻读：在一个事务里面的操作中发现了未被操作的数据。 幻读，需要应用使用加锁读来保证

IOC public class IServiceImpl implements IService {　　 public void IserviceImpl(){}　　 @Override public void getService() { System.out.println("服务"); } } applicationContext.xml <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> <bean id="myService" class="com.pack.Service.IServiceImpl"/> </beans> ApplicationContext来加载类 　　通过ClassPathXmlApplicationContext来加载类

InnoDB 有两块非常重要的日志，一个是undo log，另外一个是redo log，前者用来保证事务的原子性以及InnoDB的MVCC，后者用来保证事务的持久性。和大多数关系型数据库一样，InnoDB记录了对数据文件的物理更改，并保证总是日志先行，也就是所谓的WAL（Write Ahead Log），即在持久化数据文件前，保证之前的redo日志已经写到磁盘 一、概念 1、Innodb Crash Recovery 这是InnoDB引擎的一个特点，当故障发生，重新启服务后，会自动完成恢复操作，将数据库恢复到之前一个正常状态（不需要重做所有的日志，只需要执行上次刷入点之后的日志，这个点就叫做Checkpoint）恢复过程有两步 第一步：检查redo日志，将之前完成并提交的事务全部重做； 第二步：将undo日志中，未完成提交的事务，全部取消 2、LSN LSN(log sequence number) 用于记录日志序号，它是一个不断递增的 unsigned long long 类型整数。 在 InnoDB 的日志系统中，LSN 无处不在，它既用于表示修改脏页时的日志序号，也用于记录checkpoint，通过LSN，可以具体的定位到其在redo log文件中的位置。 LSN 用字节偏移量来表示。每个page有LSN，redo log也有LSN，Checkpoint也有LSN

概述： 事务是由一系列语句构成的逻辑工作单元。事务和存储过程等批处理有一定程度上的相似之处， 通常都是为了完成一定业务逻辑而将一条或者多条语句“封装”起来，使它们与其他语句之间出现一个逻辑上的边界，并形成相对独立的一个工作单元。 当使用事务修改多个数据表时，如果在处理的过程中出现了某种错误，例如系统死机或突然断电等情况，则返回结果是数据全部没有被保存。 因为事务处理的结果只有两种：一种是在事务处理的过程中，如果发生了某种错误则整个事务全部回滚，使所有对数据的修改全部撤销，事务对数据库的操作是单步执行的，当遇到错误时可以随时回滚； 另一种是如果没有发生任何错误且每一步的执行都成功，则整个事务全部被提交。从而可以看出，有效地使用事务不但可以提高数据的安全性，还可以增强数据的处理效率。 MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，你既需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，这样，这些数据库操作语句就构成一个事务！ 在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。 事务处理可以用来维护数据库的完整性，保证成批的 SQL 语句要么全部执行，要么全部不执行。 事务用来管理 insert,update,delete 语句 事务包含四种重要的属性，被统称为ACID