MySQL事务原理与优化最佳实践

目录

概述

事务及其ACID属性

并发事务处理带来的问题

事务的隔离级别

隔离级别分析

读未提交（Read uncommitted）

读已提交（Read Committed）

可重复读（Repeated Read）

串行化（Serializable）

事务优化

大事务的影响

事务优化实践原则

---

概述

我们的数据库一般都会并发执行多个事务，多个事务可能会并发的对相同的一批数据进行增删改查操作，可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。

这些问题的本质都是数据库的多事务并发问题，为了解决多事务并发问题，数据库设计了事务隔离机制、锁机制、MVCC多版本并发控制隔离机制，用一整套机制来解决多事务并发问题。

事务及其ACID属性

事务是由一组SQL语句组成的逻辑处理单元，事务主要有以下4个属性，通常简称为事务的ACID属性。

• 原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全部执行，要么全部不执行。
• 一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性。
• 隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。隔离性由MySQL的各种锁以及MVCC机制来实现的。
• 持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。

并发事务处理带来的问题

• 更新丢失或脏写

当两个或多个事务选择同一行，然后基于最先选定的值更新改行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题--最后的更新覆盖了由其他事务提交的更新

• 脏读

一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致的状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此作进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象的叫做“脏读”。

一句话解释：事务A读到了事务B已经修改但尚未提交的数据，还在这个数据基础上做了操作。此时B事务回滚，A读取的数据无效，不符合一致性要求。

• 不可重读

一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致的状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此作进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象的叫做“脏读”。

一句话：事务A内部相同的查询语句在不同时刻读取的结果不一致，不符合隔离性。

• 幻读

一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数

据，这种现象就称为“幻读”。

一句话：事务A读到了事务B提交的新增数据，不符合隔离性。

事务的隔离级别

隔离级别	脏读	不可重复读	幻读
读未提交（Read uncommitted）	可能	可能	可能
读已提交（Read committed）	不可能	可能	可能
可重复读（Repeated Read）	不可能	不可能	可能
串行化（Serializable）	不可能	不可能	不可能

隔离级别分析

以account表数据为例进行演示，原表数据如下：

读未提交（Read uncommitted）

（1）第一个客户端，第一次执行：

执行更新语句后查询：

（2）第二个客户端，查询结果：

（3）原表数据为：

所以读未提交隔离级别下是会读到没有提交的记录的，会存在脏读的问题。

读已提交（Read Committed）

（1）第一个客户端，第一次执行查询：

更新余额后查询：

（2）第二个客户端查询结果：

可以看到第一个客户端更新后再次查询时，数据变为15000，而打开新客户端查询时数据仍为10000，产生了不可重复读的问题。

可重复读（Repeated Read）

（1）第一个客户端，第一次查询：

（2）第一个客户端不提交，打开第二个客户端

第一次查询：

更新后查询：

（3）返回到第一个客户端再次查询

第二个客户端提交后再次查询：

发现在可重复读隔离级别下，只要开启了一个事务，在没有提交事务之前，其他事务对该数据的更改都不会影响当前数据查询结果。

串行化（Serializable）

（1）打开第一个客户端，查询：

（2）打开第二个客户端，查询：

执行更新操作后查询：

（3）返回第一个客户端执行更新：

发现执行卡住，因为第二个客户端的事务没有提交，待提交后查看

由此可以看出串行化多个事务的读写操作是互斥的，在该模式下是会对数据进行加锁的，一个事务没有提交之前另一个事务是不能对数据进行更改的。

事务优化

大事务的影响

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

事务优化实践原则

• 将查询等数据准备操作放到事务外
• 事务中避免远程调用，远程调用注意设置超时，防止事务等待时间太久
• 事务中避免一次性处理太多数据，可以拆分成多个事务分次处理
• 更新等涉及加锁的操作尽可能放在事务靠后的位置

举例：下单时会涉及insert订单表、update库存两步操作，update最好放在后面执行，因为insert一条新的 记录，在插入的过程中是不会阻塞其他事务的更新操作的，而update是更新已有的数据，如果放在前面，其他事务可能等待会存在等待的可能，放在后面更新完毕立马提交则会大大减少等待的时间。

• 能异步处理的尽量异步处理
• 应用侧（业务代码）保证数据一致性，非事务执行