MySQL事务详解

概述

事务是作为一个逻辑单元执行的一系列操作,一个逻辑工作单元必须有四个属性,称为ACID(原子性、一致性、隔离性和持久性)属性,只有这样才能成为一个事务。

我们的数据库一般都会并发执行多个事务,多个事务可能会并发的对相同的一批数据进行增删改查操作,可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。这些问题的本质都是数据库的多事务并发问题,为了解决多事务并发问题,数据库设计了事务隔离机制、锁机制、MVCC多版本并发控制隔离机制、日志机制,用一整套机制来解决多事务并发问题。

事务的四大特性(ACID)

原子性(Atomicity): 事务是一个完整的操作,事务的每个操作是不可分的,要么都执行,要么都不执行。原子性由undo log日志来实现。
一致性(Consistency): 当事务完成时,数据必须处于一致状态。
隔离性(Isolation): 并发事务之间彼此隔离、独立,一个用户的事务不被其他事务所干扰,各并发事务之间数据库是独立的。隔离性由MySQL的各种锁以及MVCC机制来实现。
持久性(Durability): 事务完成后,对数据库的修改永久保持。持久性由redo log日志来实现。

事务并发问题

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

事务隔离级别

隔离级别 脏读 不可重复读 幻读
ReadUncommitted(读取未提交)
ReadCommitted(读已提交)
RepeatableRead(可重复读)
Serializable(串行化)

数据库的事务隔离越严格,并发副作用越小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度上“串行化”进行,这显然与“并发”是矛盾的。

同时,不同的应用对读一致性和事务隔离程度的要求也是不同的,比如许多应用对“不可重复读"和“幻读”并不敏感,可能更关心数据并发访问的能力。

查看当前数据库的事务隔离级别::show variables like ‘tx_isolation’;
设置事务隔离级别:set tx_isolation=‘REPEATABLE-READ’;

Mysql默认的事务隔离级别是可重复读,用Spring开发程序时,如果不设置隔离级别默认用Mysql设置的隔离级别,如果Spring设置了就用已经设置的隔离级别。

事务隔离级别案例分析

示例表

DROP TABLE IF EXISTS `account`;
CREATE TABLE `account`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL,
  `balance` int(11) NULL DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 4 CHARACTER SET = utf8 COLLATE = utf8_bin ROW_FORMAT = Dynamic;

INSERT INTO `account` VALUES (1, 'zhangsan', 0);
INSERT INTO `account` VALUES (2, 'xiaoming', 1000);
INSERT INTO `account` VALUES (3, 'hanmei', 15000);

ReadUncommitted(读取未提交)

1)事务A,设置当前事务模式为read uncommitted(未提交读),查询account表。此时事务A未提交。

set tx_isolation='read-uncommitted';

BEGIN;
SELECT * FROM account;

#COMMIT;

MySQL事务详解_第1张图片

2)事务B,设置当前事务模式为read uncommitted(未提交读),更新id=1的balance字段,此时事务B未提交。

set tx_isolation='read-uncommitted';

BEGIN;

UPDATE account set balance = 500 WHERE id = 1;

#COMMIT;

3)事务B还未提交,事务A查询account表,但是事务A就可以查询到事务B已经更新的数据。

SELECT * FROM account;

MySQL事务详解_第2张图片

一旦事务B因为某种原因回滚,所有的操作都将会被撤销,那事务A查询到的数据其实就是脏数据。

ReadCommitted(读已提交)

1)事务A,设置当前事务模式为ReadCommitted(读已提交),查询表account的所有记录。此时事务A未提交。

set tx_isolation='read-committed';

BEGIN;

SELECT * FROM account;

#COMMIT;

MySQL事务详解_第3张图片
2)事务B,设置当前事务模式为ReadCommitted(读已提交),更新id=1的balance字段,此时事务B未提交。

set tx_isolation='read-committed';
BEGIN;

UPDATE account set balance = 1000 WHERE id = 1;


#COMMIT;

3)此时,事务B的事务还没提交,事务A不能查询到事务B已经更新的数据,解决了脏读问题。

SELECT * FROM account;

MySQL事务详解_第4张图片

4)事务B的事务提交了,事务A第一次查询的数据和第二次查询的数据不一致,即产生了不可重复读的问题。

MySQL事务详解_第5张图片
MySQL事务详解_第6张图片

RepeatableRead(可重复读)

这个隔离级别记住一句话就能理解:可重复读隔离级别在事务开启的时候,第一次查询是查的数据库里已提交的最新数据,这时候全数据库会有一个快照(当然数据库并不是真正的生成了一个快照,这个快照机制怎么实现的后面课程会详细讲),在这个事务之后执行的查询操作都是查快照里的数据,别的事务不管怎么修改数据对当前这个事务的查询都没有影响,但是当前事务如果修改了某条数据,那当前事务之后查这条修改的数据就是被修改之后的值,但是查其它数据依然是从快照里查,不受影响。

1)事务A,设置当前事务模式为RepeatableRead(可重复读),查询表account的所有记录。此时事务A未提交。

set tx_isolation='repeatable-read';
BEGIN;

SELECT * FROM account;

#COMMIT;

MySQL事务详解_第7张图片

2)事务B,设置当前事务模式为RepeatableRead(可重复读),更新id=1的balance字段,此时事务B已提交。

set tx_isolation='repeatable-read';
BEGIN;

UPDATE account set balance = 1500 WHERE id = 1;

COMMIT;

3)事务A,第一次查询和第二次查询的所有记录是一致的,没有出现不可重复读问题。

SELECT * FROM account;

MySQL事务详解_第8张图片
4)在事务A,接着执行update account set balance = balance - 200 where id = 1,balance没有变成1000-200=800,zhangsan的balance值用的是步骤2中的1500来算的,所以是1300,数据的一致性倒是没有被破坏。可重复读的隔离级别下使用了MVCC(multi-version concurrency control)机制,select操作是快照读(历史版本);insert、update和delete是当前读(当前版本)。

update account set balance = balance - 200 where id = 1;
SELECT * FROM account;

MySQL事务详解_第9张图片
5)事务C,设置当前事务模式为RepeatableRead(可重复读),插入一条新数据,然后提交事务。

set tx_isolation='repeatable-read';
BEGIN;

INSERT INTO `account` VALUES (4, 'lisi', 300);

COMMIT;

6)事务A查询表account的所有记录,没有查出新增数据,所以没有出现幻读。

SELECT * FROM account;

MySQL事务详解_第10张图片

7)验证幻读

事务A执行update account set balance = 888 where id = 4,能更新成功,再次查询就能查到事务C插入的数据。

update account set balance = 888 where id = 4;
SELECT * FROM account;

MySQL事务详解_第11张图片

Serializable(串行化)

1)事务A,设置当前事务模式为Serializable(串行化),查询表account,id=1的数据。此时事务A未提交。

set tx_isolation='serializable';
BEGIN;

SELECT * FROM account WHERE id = 1;


#COMMIT;

2)事务B,设置当前事务模式为serializable,更新相同的id为1的记录会被阻塞等待,更新id为2的记录可以成功,说明在串行模式下innodb的查询也会被加上行锁,如果查询的记录不存在会给这条不存在的记录加上锁(这种是间隙锁,后面会详细讲)。

如果客户端A执行的是一个范围查询,那么该范围内的所有行包括每行记录所在的间隙区间范围都会被加锁。此时如果客户端B在该范围内插入数据都会被阻塞,所以就避免了幻读。

这种隔离级别并发性极低,开发中很少会用。

set tx_isolation='serializable';
BEGIN;

UPDATE account set balance = 5000 WHERE id = 1

#COMMIT;

事务问题定位

#查询执行时间超过1秒的事务,详细的定位问题方法后面讲完锁课程后会一起讲解
SELECT
	* 
FROM
	information_schema.innodb_trx 
WHERE
	TIME_TO_SEC( timediff( now( ), trx_started ) ) > 1;
 
 #强制结束事务
kill 事务对应的线程id(就是上面语句查出结果里的trx_mysql_thread_id字段的值)

你可能感兴趣的:(mysql,数据库)