5、Mysql事务原理

一、概述

事务：一组操作要么全部成功，要么全部失败，目的是为了保证数据最终的一致性。
数据库一般都会并发执行多个事务，多个事务可能会并发的对相同的一批数据进行增删改查操作，可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。
这些问题的本质都是数据库的多事务并发问题，为了解决多事务并发问题，数据库设计了事务隔离机制、锁机制、MVCC多版本并发控制隔离机制、日志机制，用一整套机制来解决多事务并发问题

二、ACID

事务具有以下4个属性,通常简称为事务的ACID属性。
● 原子性(Atomicity) ：当前事务的操作要么同时成功，要么同时失败。原子性由undo log日志来实现。
● 一致性(Consistent) ：使用事务的最终目的，由其它3个特性以及业务代码正确逻辑来实现。
● 隔离性(Isolation) ：在事务并发执行时，他们内部的操作不能互相干扰。隔离性由MySQL的各种锁以及MVCC机制来实现。
● 持久性(Durable) ：一旦提交了事务，它对数据库的改变就应该是永久性的。持久性由redo log日志来实现

三、并发事务处理带来的问题

更新丢失(Lost Update)或脏写	当两个或多个事务选择同一行数据修改，有可能发生更新丢失问题，即最后的更新覆盖了由其他事务所做的更新
脏读(Dirty Reads)	事务A读取到了事务B已经修改但尚未提交的数据
不可重读(Non-Repeatable Reads)	事务A内部的相同查询语句在不同时刻读出的结果不一致
幻读(Phantom Reads)	事务A读取到了事务B提交的新增数据

四、事务隔离级别

脏读、不可重复读和幻读，都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。

隔离级别	脏读(Dirty Read)	不可重复读(NonRepeatable Read)	幻读(Phantom Read)
读未提交(Read uncommitted)	可能	可能	可能
读已提交(Read committed)	不可能	可能	可能
可重复读(Repeatableread)	不可能	不可能	可能
可串行化(Serializable)	不可能	不可能	可能不可能

数据库的事务隔离越严格,并发副作用越小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度上“串行化”进行,这显然与“并发”是矛盾的。
不同的应用对读一致性和事务隔离程度的要求也是不同的,比如许多应用对“不可重复读"和“幻读”并不敏感,可能更关心数据并发访问的能力。
查看当前数据库的事务隔离级别: show variables like ‘tx_isolation’;
设置事务隔离级别：set tx_isolation=‘REPEATABLE-READ’;
Mysql默认的事务隔离级别是可重复读（Oracle默认事务为读已提交），用Spring开发程序时，如果不设置隔离级别默认用Mysql设置的隔离级别，如果Spring设置了就用已经设置的隔离级别。

查看和设置mysql事务隔离级别

--当前会话隔离级别
select @@transaction_isolation;
--系统隔离级别
select @@global.transaction_isolation;

--MySQL 5.7.20前可以使用
set tx_isolation='read-uncommitted';
--MySQL 5.7.20后弃用tx_isolation
set session transaction isolation level read uncommitted;--设置读未提交
set session transaction isolation level read committed;--设置读已提交
set session transaction isolation level  repeatable read;--设置可重复读
set session transaction isolation level Serializable;--可串行化

事务隔离级别案例分析

表结构与数据

CREATE TABLE `account`(
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`balance` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `account` (`name`, `balance`) VALUES ('lilei', '450');
INSERT INTO `account` (`name`, `balance`) VALUES ('hanmei', '16000');
INSERT INTO `account` (`name`, `balance`) VALUES ('lucy', '2400');

读未提交(Read uncommitted)

打开两个窗口设置隔离级别为 读未提交(Read uncommitted)

select @@transaction_isolation;
set session transaction isolation level read uncommitted;
select  * from account;
update account a set a.balance=500 where a.id='1';

select @@transaction_isolation;
set session transaction isolation level read uncommitted;
select  * from account;

读未提交存在问题：
一旦客户端console_1的事务因为某种原因回滚，所有的操作都将会被撤销，那客户端console_2查询到的数据其实就是脏数据
注意：如果事务1修改lilei金额为500时候，没有提交事务。事务2这个时候去做查询，查询到金额为500，想要做增加50的业务逻辑，请使用

--请使用
update account a set a.balance=a.balance+50 where a.id='1';
--不能用
update account a set a.balance=550 where a.id='1';

这个操作来完成，如果直接设置balance为550，一旦事务1回滚必定造成脏数据，因为同时对id为1的数据进行修改是会加写锁的，使用balance+50情况下事务1回滚，这里的banlance就是450而不是500了。

读已提交(Read committed)

打开两个窗口设置隔离级别为 读已提交(Read committed)

select @@transaction_isolation;
set  session transaction isolation level read committed;
select  * from account;
update account a set a.balance=500 where a.id='1';

select @@transaction_isolation;
set  session transaction isolation level read committed;
--事务1未提交 450
select  * from account;
--事务1提交了 500
select  * from account;

读已提交存在问题：

同一个事务下面两次查询到的值不同，即产生了不可重复读的问题。

可重复读(Repeatableread)

可重复读隔离级别在事务开启的时候，第一次查询是查的数据库里已提交的最新数据，这时候全数据库会有一个快照(当然数据库并不是真正的生成了一个快照)，在这个事务之后执行的查询操作都是查快照里的数据，别的事务不管怎么修改数据对当前这个事务的查询都没有影响，但是当前事务如果修改了某条数据，那当前事务之后查这条修改的数据就是被修改之后的值，但是查其它数据依然是从快照里查，不受影响。
打开两个窗口设置隔离级别为 可重复读(repeatable read)

set  session transaction isolation level repeatable read;
select @@transaction_isolation;
select  * from account;
update account a set a.balance=500 where a.id='1';

set  session transaction isolation level repeatable read;
select @@transaction_isolation;
--事务1未提交 450
select  * from account;
--事务1提交了 450 提交后真实为500
select  * from account;

这时候如果在事务2这里，进行lilie的balance+50，结果是550而不是500

update account a set a.balance=balance+50 where a.id='1';

可重复读的隔离级别下使用了MVCC(multi-version concurrency control)机制，select操作是快照读（历史版本）；insert、update和delete是当前读（当前版本）

insert into account(name, balance) value ('zk',1000);

select @@transaction_isolation;
set  session transaction isolation level repeatable read;
#事务1未提交 插入一条数据
select  * from account;
#事务1提交了 还是未查询到新增数据
select  * from account;
update account a set a.balance=balance+50 where a.id=4;
select  * from account;

可串行化(Serializable)

打开两个窗口设置隔离级别为 串行化

select @@transaction_isolation;
set  session transaction isolation level serializable;
select  * from account a where a.id=1;

select @@transaction_isolation;
set  session transaction isolation level serializable;
--事务1未提交
update account a set a.balance=balance+50 where a.id=1;

说明在串行模式下innodb的查询也会被加上行锁，如果查询的记录不存在会给这条不存在的记录加上锁(这种是间隙锁)。
如果客户端1执行的是一个范围查询，那么该范围内的所有行包括每行记录所在的间隙区间范围都会被加锁。此时如果客户端2在该范围内插入数据都会被阻塞，所以就避免了幻读。
这种隔离级别并发性极低，开发中很少会用。

事务问题定位

--查询执行时间超过1秒的事务
SELECT
*
FROM
information_schema.innodb_trx
WHERE
TIME_TO_SEC( timediff( now( ), trx_started ) ) > 1;
--强制结束事务
--kill 事务对应的线程id(就是上面语句查出结果里的trx_mysql_thread_id字段的值)

五、大事务的影响

● 并发情况下，数据库连接池容易被撑爆
● 锁定太多的数据，造成大量的阻塞和锁超时
● 执行时间长，容易造成主从延迟
● 回滚所需要的时间比较长
● undo log膨胀
● 容易导致死锁

六、事务优化

● 将查询等数据准备操作放到事务外
● 事务中避免远程调用，远程调用要设置超时，防止事务等待时间太久
● 事务中避免一次性处理太多数据，可以拆分成多个事务分次处理
● 更新等涉及加锁的操作尽可能放在事务靠后的位置
● 能异步处理的尽量异步处理
● 应用侧(业务代码)保证数据一致性，非事务执行