Mysql-5.Mysql事务原理与优化最佳实践

飞越沧海的蝴蝶

已于 2023-09-14 20:30:51 修改

阅读量161

点赞数 1

分类专栏： Java架构学习之旅文章标签： mysql 数据库 java

于 2023-09-13 20:46:23 首次发布

本文链接：https://blog.csdn.net/weixin_42287045/article/details/132864471

版权

Java架构学习之旅专栏收录该内容

24 篇文章 0 订阅

订阅专栏

学习内容重点：

1、深入理解Innodb底层事务实现机制

2、从undo与redo日志理解事务ACID底层原理

3、事务四大隔离级别详解以及如何选择

4、事务底层锁机制与MVCC并发优化机制初探

5、剖析查询操作方法需要使用事务吗

6、BufferPool缓存与redo日志是如何提升事务性能的

7、redo日志磁盘顺序写机制

8、从事务底层实现理解Mysql为什么不会丢数据

9、Mysql事务优化最佳实践

事务

一组操作要么全部成功，要么全部失败，目的是为了保证数据最终的一致性。

事务的特性

事务具有以下4个属性,通常简称为事务的ACID属性。

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

ps:

一致性的业务代码正确逻辑来实现举例：

例如:下单操作，生成订单成功，减库存失败了，外面加try,catch,只加了一条日志记录不抛异常，spring就没法回滚事务

InnoDB引擎中，定义了四种隔离级别供我们使用，级别越高事务隔离性越好，但性能就越低，而隔离性是由MySQL的各种锁以及MVCC机制来实现的

read uncommit (读未提交) ：脏读

read commit (读已提交)：不可重复读

repeatable read (可重复读) ：幻读

serializable (串行)：解决上面所有问题，包括脏写

并发事务处理带来的问题

更新丢失(Lost Update)或脏写

　　当两个或多个事务选择同一行数据修改，有可能发生更新丢失问题，即最后的更新覆盖了由其他事务所做的更新。

脏读（Dirty Reads）

　　事务A读取到了事务B已经修改但尚未提交的数据

不可重读（Non-Repeatable Reads）

　事务A内部的相同查询语句在不同时刻读出的结果不一致

幻读（Phantom Reads）

　事务A读取到了事务B提交的新增数据

事务隔离级别

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

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

查看当前数据库的事务隔离级别: show variables like 'tx_isolation';

设置事务隔离级别：set tx_isolation='REPEATABLE-READ';

Mysql默认的事务隔离级别是可重复读，Oracle默认的事务隔离级别是读已提交。

事务隔离级别案例分析

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 `test1`.`account` (`name`, `balance`) VALUES ('lilei', '450');
INSERT INTO `test1`.`account` (`name`, `balance`) VALUES ('hanmei', '16000');
INSERT INTO `test1`.`account` (`name`, `balance`) VALUES ('lucy', '2400');

1.读未提交：

（1）打开一个客户端A，并设置当前事务模式为read uncommitted（读未提交），查询表account的初始值：

set tx_isolation='read-uncommitted';

（2）在客户端A的事务提交之前，打开另一个客户端B，更新表account：

（3）这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更新的数据：

（4）一旦客户端B的事务因为某种原因回滚，所有的操作都将会被撤销，那客户端A查询到的数据其实就是脏数据：

（5）在客户端A执行更新语句update account set balance = balance - 50 where id =1，lilei的balance没有变成400，是900，数据不一致，因为在应用程序中，我们会用950-50=900，并不知道其他会话回滚了，要想解决这个问题可以采用读已提交的隔离级别

2、读已提交

（1）打开一个客户端A，并设置当前事务模式为read committed（未提交读），查询表account的所有记录：

set tx_isolation='read-committed';

（2）在客户端A的事务提交之前，打开另一个客户端B，更新表account：

（3）这时，客户端B的事务还没提交，客户端A不能查询到B已经更新的数据，解决了脏读问题：

（4）客户端B的事务提交

（5）客户端A执行与上一步相同的查询，结果为更新后的结果，但是这步的结果与上一步不一致，即产生了不可重复读的问题

3、可重复读

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

（1）打开一个客户端A，并设置当前事务模式为repeatable read，查询表account的所有记录

set tx_isolation='repeatable-read';

（2）在客户端A的事务提交之前，打开另一个客户端B，更新表account并提交

（3）在客户端A查询表account的所有记录，与步骤（1）查询结果一致，没有出现不可重复读的问题

（4）在客户端A，接着执行update account set balance = balance - 50 where id = 1，balance没有变成450-50=400，lilei的balance值用的是步骤2中的950来算的，所以是900，数据的一致性倒是没有被破坏。可重复读的隔离级别下使用了MVCC(multi-version concurrency control)机制，select操作是快照读（历史版本）；insert、update和delete是当前读（当前版本）。

（5）重新打开客户端B，插入一条新数据后提交

（6）在客户端A查询表account的所有记录，没有查出新增数据，所以没有出现幻读

（7)验证幻读

在客户端A执行update account set balance=888 where id = 4；能更新成功，再次查询能查到客户端B新增的数据

4、串行化

（1）打开一个客户端A，并设置当前事务模式为serializable，查询表account的初始值：

set tx_isolation='serializable';

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

更新相同的id为1的记录会被阻塞等待，更新id为2的记录可以成功，说明在串行模式下innodb的查询也会被加上行锁

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

A事务端提交事务后，可以执行新增数据

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

读锁（共享锁、S锁）：select...lock in share mode;

读锁是共享的，多个事务可以同时读取同一个资源，但不允许其他事务修改

写锁（排它锁、X锁）：select...for update；

写锁是排他的，会阻塞其他的写锁和读锁，update、delete、insert都会加写锁

MVCC(Multi-VersionConcurrency Control)多版本并发控制

就可以做到读写不阻塞，且避免了类似脏读这样的问题，主要通过undo日志链来实现

select操作是快照读（历史版本）

insert、update和delete是当前读（当前版本）

readcommit (读已提交) ，语句级快照

repeatableread (可重复读)，事务级快照

图示：

查询操作方法需要使用事务吗？

具体还是看业务场景，根据实际需求来选择。

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

事务的持久性宏观了解（后面一篇从原理详解）

MySQL引入了redolog，Buffer Pool内存写完了，然后会写一份redo log，这份redo log记载着这次在某个页上做了什么修改。

即便MySQL在中途挂了，我们还可以根据redolog来对数据进行恢复。

redolog 是顺序写的，写入速度很快。并且它记录的是物理修改（xxxx页做了xxx修改），文件的体积很小，恢复速度也很快。

大事务的影响

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

事务优化

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

飞越沧海的蝴蝶

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
Mysql-5.Mysql事务原理与优化最佳实践

1、深入理解Innodb底层事务实现机制2、从undo与redo日志理解事务ACID底层原理3、事务四大隔离级别详解以及如何选择4、事务底层锁机制与MVCC并发优化机制初探5、剖析查询操作方法需要使用事务吗6、BufferPool缓存与redo日志是如何提升事务性能的7、redo日志磁盘顺序写机制8、从事务底层实现理解Mysql为什么不会丢数据9、Mysql事务优化最佳实践
复制链接

扫一扫