MySql事务

最新推荐文章于 2024-04-01 20:13:50 发布

程序员子衿

最新推荐文章于 2024-04-01 20:13:50 发布

阅读量241

点赞数

本文链接：https://blog.csdn.net/Jim_ZTR/article/details/127296838

版权

Java 同时被 2 个专栏收录

33 篇文章 1 订阅

订阅专栏

数据库

6 篇文章 0 订阅

订阅专栏

1.事务介绍

l 事务的概念

事务指逻辑上的一组操作，组成这组操作的各个单元，要不全部成功，要不全部不成功

l 数据库开启事务命令

start transaction 开启事务（等同于set autocommit = off ）

Rollback 回滚事务

Commit 提交事务

2.Mysql中使用事务

1.创建表

create table t_account(

id int primary key auto_increment,

name varchar(20),

money double

);

insert into t_account values(null,'aaa',1000);

insert into t_account values(null,'bbb',1000);

insert into t_account values(null,'ccc',1000);

2、MySQL中事务默认自动提交的，每当执行一条SQL，就会提交一个事务（一条SQL 就是一个事务）

Oracle 中事务默认不自动提交，需要在执行SQL 语句后通过commint 手动提交事务

3、mysql管理事务

方式一：同时事务管理SQL 语句

start transaction 开启事务

rollback 回滚事务（将数据恢复到事务开始时状态）

commit 提交事务（对事务中进行操作，进行确认操作，事务在提交后，数据就不可恢复）

方式二：数据库中存在一个自动提交变量，通过 show variables like '%commit%'; ---- autocommint 值是 on，说明开启自动提交

关闭自动提交 set autocommit = off / set autocommit = 0

如果设置autocommit 为 off，意味着以后每条SQL 都会处于一个事务中，相当于每条SQL执行前都会执行

start transaction

补充：Oracle中autocommit 默认是 off

3.Jdbc使用事务

l 当Jdbc程序向数据库获得一个Connection对象时，默认情况下这个Connection对象会自动向数据库提交在它上面发送的SQL语句。若想关闭这种默认提交方式，让多条SQL在一个事务中执行，可使用下列语句：

l JDBC控制事务语句

Connection.setAutoCommit(false); // 相当于start transaction

Connection.rollback(); rollback

Connection.commit(); commit

4.事务特性(ACID)

原子性（Atomicity）原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。

一致性（Consistency）事务前后数据的完整性必须保持一致。

隔离性（Isolation）事务的隔离性是指多个用户并发访问数据库时，一个用户的事务不能被其它用户的事务所干扰，多个并发事务之间数据要相互隔离。

持久性（Durability）

持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。

5.隔离级别

多个线程开启各自事务操作数据库中数据时，数据库系统要负责隔离操作，以保证各个线程在获取数据时的准确性

数据库内部定义了四种隔离级别，用于解决三种隔离问题

1 Serializable：可避免脏读、不可重复读、虚读情况的发生。（串行化）

2 Repeatable read：可避免脏读、不可重复读情况的发生。（可重复读）不可以避免虚读（幻读）

3 Read committed：可避免脏读情况发生（读已提交）

4 Read uncommitted：最低级别，以上情况均无法保证。(读未提交)

怎样设置事务的隔离级别?

mysql中设置

1.查看事务隔离级别

select @@tx_isolation 查询当前事务隔离级别

mysql中默认的事务隔离级别是 Repeatable read.

扩展:oracle 中默认的事务隔离级别是 Read committed

2.mysql中怎样设置事务隔离级别

set session transaction isolation level 设置事务隔离级别

jdbc中设置

JDBC程序中能否指定事务的隔离级别？

Connection接口中定义事务隔离级别四个常量：

static int TRANSACTION_READ_COMMITTED

指示不可以发生脏读的常量；不可重复读和虚读可以发生。

static int TRANSACTION_READ_UNCOMMITTED

指示可以发生脏读 (dirty read)、不可重复读和虚读 (phantom read) 的常量。

static int TRANSACTION_REPEATABLE_READ

指示不可以发生脏读和不可重复读的常量；虚读可以发生。

static int TRANSACTION_SERIALIZABLE

指示不可以发生脏读、不可重复读和虚读的常量。

通过 void setTransactionIsolation(int level) 设置数据库隔离级别

如果不考虑隔离性，可能会引发如下问题：

1、脏读：指一个事务读取另一个事务未提交的数据

A 转账给B 100，未提交

B 查询账户多了100

A 回滚

B 查询账户那100不见了

2、不可重复读：在一个事务先后两次读取发生数据不一致情况，第二次读取到另一个事务已经提交数据（强调数据更新 update）

A 查询账户 5000

B 向 A 账户转入 5000

A 查询账户 10000

3、虚读(幻读) ：在一个事务中，第二次读取发生数据记录数的不同，读取到另一个事务已经提交数据（强调数据记录变化 insert ）

A 第一次读取存在5条记录

B 向 A 插入一条新的记录

A 第二次读取存在6条记录

4、丢失更新：两个事务对同一条记录进行操作，后提交的事务，将先提交的事务的修改覆盖了。

演示：脏读

一个事务读取到另一个事务的未提交数据

设置A,B事务隔离级别为 Read uncommitted

set session transaction isolation level read uncommitted;

在A事务中

start transaction;

update account set money=money-500 where name='aaa';

update account set money=money+500 where name='bbb';

在B事务中

start transaction;

select * from account;

这时，B事务读取时，会发现，钱已经汇完。那么就出现了脏读。

当A事务提交前，执行rollback，在commit， B事务在查询，就会发现，钱恢复成原样

也出现了两次查询结果不一致问题，出现了不可重复读.

解决脏读问题

将事务的隔离级别设置为 read committed来解决脏读

设置A,B事务隔离级别为 Read committed

set session transaction isolation level read committed;

在A事务中

start transaction;

update account set money=money-500 where name='aaa';

update account set money=money+500 where name='bbb';

在B事务中

start transaction;

select * from account;

这时B事务中，读取信息时，是不能读到A事务未提交的数据的，也就解决了脏读。让A事务，提交数据 commit;

这时，在查询，这次结果与上一次查询结果又不一样了，还存在不可重复读。

解决不可重复读

将事务的隔离级别设置为Repeatable read来解决不可重复读。

设置A,B事务隔离级别为 Repeatable read;

set session transaction isolation level Repeatable read;

1.在A事务中

start transaction;

update account set money=money-500 where name='aaa';

update account set money=money+500 where name='bbb';

2.在B事务中

start transaction;

select * from account;

当A事务提交后commit;B事务在查询，与上次查询结果一致，解决了不可重复读。

设置事务隔离级别 Serializable ,它可以解决所有问题

set session transaction isolation level Serializable;

如果设置成这种隔离级别，那么会出现锁表。也就是说，一个事务在对表进行操作时，其它事务操作不了。

总结:

脏读:一个事务读取到另一个事务未提交数据

不可重复读:两次读取数据不一致(读提交数据)---update

虚读:两次读取数据不一致(读提交数据)----insert

事务隔离级别:

read uncommitted 什么问题也解决不了.

read committed 可以解决脏读，其它解决不了.

Repeatable read 可以解决脏读，可以解决不可重复读,不能解决虚读.

Serializable 它会锁表，可以解决所有问题.

安全性：serializable > repeatable read > read committed > read uncommitted

性能：serializable < repeatable read < read committed < read uncommitted

结论：实际开发中，通常不会选择 serializable 和 read uncommitted ，

mysql默认隔离级别 repeatable read ，oracle默认隔离级别 read committed

6.丢失更新

丢失更新：多个事务对同一条记录进行了操作，后提交的事务将先提交的事务操作覆盖了。

问题：怎样解决丢失更新问题?

解决丢失更新可以采用两种方式:

1.悲观锁（假设丢失更新一定会发生）

悲观锁原理：使用数据库内部锁机制，进行数据库表的锁定，就是在A管理员修改数据时，A管理员就将数据锁定，此时B管理员无法进行修改、查询。避免两个事务同时修改，也就解决了丢失更新问题。

1.共享锁（读锁），首先开启事务：start transaction;

select * from 表名 lock in share mode（在读取数据时加锁）

此时该表就被加上了读锁，只允许加锁的事务修改（哪个窗口执行该语句，哪个窗口可以进行删除，修改操作）

但是，如果在两个窗口都执行该语句，则会因为两个窗口都在互相等待对方释放锁从而发生死锁问题，强调一下，读锁是非常容易发生死锁问题的。

2.排它锁（写锁）

一张表只能加一个排它锁，排它锁和其它的共享锁都具有互斥效果。通俗一点说就是，一张表如果想加排它锁，在它之前，就不能加别的共享锁和排它锁。当一张表在一个事务中加上了写锁后，别的事务将不能够修改该表数据，因为修改数据会自动加上读锁，进而产生互斥。

select * from 表名 for update （在修改数据时加锁）

注：update语句默认添加排它锁（对同一条数据操作时）

2.乐观锁

乐观锁（假设丢失更新不会发生）------- 采用程序中添加版本字段解决丢失更新问题

让事务进行并发修改，不对事务进行锁定，由程序员自己解决，可以通过给数据表添加自增的version字段或时间戳timestamp，进行数据修改时，数据库会检测version字段或者时间戳是否与原来的一致，若不一致，抛出异常或者重新查询
CREATE TABLE t_product(
id INT,
NAME VARCHAR(20),
updatetime TIMESTAMP
)

insert into t_product values(1,'冰箱',null);

update t_product set name='洗衣机' where id = 1;
首先开启事务，A、B管理员分别查询数据并修改数据，当A管理员提交修改后，updatetime字段会自动更新为当前时间，再当B管理员修改数据并提交时，程序比较updatetime字段，发现两者并不一样，证明数据已经被修改了

解决丢失更新：在数据表添加版本字段，每次修改过记录后，版本字段都会更新，如果读取是版本字段，与修改时版本字段不一致，说明别人进行修改过数据（重改）