事务的产生是为了简化我们的编程模型,使我们在开发的过程中不用考虑各种潜在的错误和并发问题,而不是伴随着数据库系统天生就存在的。
事务支持是在引擎层实现的,InnoDB支持事务而MyISAM不支持。
假设数据库不支持事务,看下面的示例:
a账户要转给b账户100元:
update acount set amount =amount -100 where user=a // 1
update acount set amount =amount +100 where user=b // 2
假设程序第一步执行完成了执行到第2步的时候出了问题,那么将导致a账户白白少了100块。此时就能看到事务的重要性了。
在事务完成以后,该事务对数据库所作的更改便持久的保存在数据库之中,并不会被回滚。
事务隔离级别 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|
读未提交(read-uncommitted) | 是 | 是 | 是 |
读已提交(read-committed) | 否 | 是 | 是 |
可重复读(repeatable-read) | 否 | 否 | 是 |
串行化(serializable) | 否 | 否 | 否 |
MySQL
查询当前窗口的事务隔离级别
8以前:select @@tx_isolation;
8:select @@transaction_isolation;
在MySQL
中,默认的隔离级别是REPEATABLE-READ(可重复读),并且解决了幻读问题。简单的来说,mysql的默认隔离级别解决了脏读、幻读、不可重复读问题。
MySQL
是如何实现事务的首先需要了解MVCC
(Multi-Version Concurrency Control),它在许多情况下避免了使用锁,同时可以提供更小的开销。根据实现的不同,它可以允许非阻塞式读,在写操作进行时只锁定必要的记录。
InnoDB
通过为每一行记录添加两个额外的隐藏的值来实现MVCC
,这两个值一个记录这行数据何时被创建,另外一个记录这行数据何时过期(或者被删除)。但是InnoDB
并不存储这些事件发生时的实际时间,相反它只存储这些事件发生时的系统版本号。这是一个随着事务的创建而不断增长的数字。每个事务在事务开始时会记录它自己的系统版本号。每个查询必须去检查每行数据的版本号与事务的版本号是否相同。让我们来看看当隔离级别是REPEATABLE READ
时这种策略是如何应用到特定的操作的:
SELECT InnoDB
必须保证每行数据符合两个条件:
InnoDB
必须找到一个行的版本,它至少要和事务的版本一样老(也即它的版本号不大于事务的版本号)。这保证了不管是事务开始之前,或者事务创建时,或者修改了这行数据的时候,这行数据是存在的。符合这两个条件的行可能会被当作查询结果而返回。
INSERT:InnoDB为这个新行记录当前的系统版本号。
DELETE:InnoDB将当前的系统版本号设置为这一行的删除ID。
UPDATE:InnoDB
会写一个这行数据的新拷贝,这个拷贝的版本为当前的系统版本号。它同时也会将这个版本号写到旧行的删除版本里。
快照读:读取的是快照版本,也就是历史版本
当前读:读取的是最新版本
普通的SELECT就是快照读,而UPDATE、DELETE、INSERT、SELECT ... LOCK IN SHARE MODE、SELECT ... FOR UPDATE是当前读。
有这样三种锁我们需要了解:
普通的SELECT用的是一致性读不加锁。而对于锁定读、UPDATE和DELETE,则需要加锁,至于加什么锁视情况而定。如果你对一个唯一索引使用了唯一的检索条件,那么只需锁定索引记录即可;如果你没有使用唯一索引作为检索条件,或者用到了索引范围扫描,那么将会使用间隙锁或者next-key锁以此来阻塞其它会话向这个范围内的间隙插入数据。
利用MVCC
实现一致性非锁定读,这就保证在同一个事务中多次读取相同的数据返回的结果是一样的,解决了不可重复读的问题
利用Gap Locks和Next-Key可以阻止其它事务在锁定区间内插入数据,因此解决了幻读问题
MySQL
中事务操作show variables like '%autocommit%'
;// 事务是否自动提交
START TRANSACTION
;// 开启事务
COMMIT
;// 提交事务
ROLLBACK
;// 回滚事务
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.SQLException;
/**
* @Author: csj
* @Description:
* @Date: 2019/6/14 15:06
*/
public class LocalJDBCTransApplication {
private static final Logger LOG = LoggerFactory.getLogger(LocalJDBCTransApplication.class);
public static void main(String[] args) throws SQLException {
Connection connection = getConnection();
connection.setAutoCommit(false);
String sql1 = "update user set gold = gold+1 where uid = ?";
PreparedStatement ps1 = connection.prepareStatement(sql1);
ps1.setLong(1,143000164498542592L);
ps1.executeUpdate();
String sql2 = "update user set gold = gold-1 where uid = ?";
PreparedStatement ps2 = connection.prepareStatement(sql2);
ps1.setLong(1,143000164498542592L);
ps1.executeUpdate();
ps1.close();
ps2.close();
connection.close();
}
private static Connection getConnection() throws SQLException {
String driver = "com.mysql.cj.jdbc.Driver";
String url = "jdbc:mysql://localhost:3306/test";
String username = "test";
String password = "test";
try {
Class.forName(driver);
} catch (ClassNotFoundException e) {
LOG.error(e.getLocalizedMessage());
}
return DriverManager.getConnection(url,username,password);
}
}
undo用于解决事务未完成和事务回滚的情况,redo则是为了保证已经提交的事务所做的修改持久化到辅助存储。事务日志会在commit或commit之前写入持久化存储中,然后事务对数据本身的修改才能生效。因此就能够保证在系统故障时可以通过读取redo日志来重写持久化操作。