MySQL初阶学习日记（7）--- 事务

接下来我们讲到的事务也是一个面试高频考点，很重要，敲重点！！

1.事务的概念

1.1 概念

1）概念

事务是数据库管理系统中的基本操作单元，它必须满足ACID 特性（下面会介绍）从而确保数据的一致性和可靠性

2）简单理解

事务就是把一些SQL语句打包为一个整体，要么一起执行，要么都不执行

1.2 举例

事务这边有一个经典的案例：转账

可以这么理解，数据库的事务，就是用来解决**" 原子性 "**问题的！

2.事务的ACID特性（重点）

2.1 Atomicity（原子性）/ˌætəˈmɪsəti /

事务是一个不可分割的工作单元，要么全部完成，要么全部不完成，这意味着如果事务中的任何操作失败，所有已完成的操作都将被回滚，数据库的状态将保持在事务开始之前的状态

2.2 Consistency（一致性）/kənˈsɪstənsi /

事务开始前和事务开始之后，数据的完整性不会被破坏，这意味着事务的执行不能破坏数据库的完整性（具体场景具体分析，比如数据的预设规则、精度、关联性等）

2.3 Isolation（隔离性）/ˌaɪsəˈleɪʃn /

一个数据库可以同时执行多个客户端提交的事务，并且这些并发执行的事务之间是互不影响的。隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致，事务可以指定不同的隔离级别，以权衡在不同应用场景下数据库的性能和安全

2.4 Durability（持久性）/ˌdjʊərəˈbɪləti /

一旦事务成功提交，其对数据库的所有操作都是永久性的，即使系统发生故障也不会丢失

3.使用事务

在使用事务前，我们首先要明确我们的存储引擎 ，在MySQL中支持事务的存储引擎的是InnoDB，我们通过一个具体的例子来演示如何使用事务

3.1 基本语法

3.1.1 开始事务

我们开始事务的语法一般用 start transaction 或者 begin

*开始事务
start transaction;

3.1.2 提交事务

提交事务一般用 commit

*提交事务
commit;

3.1.3 回滚事务

回滚事务用 rollback

*回滚事务
rollback;

3.2 示例：开始一个事务，执行修改后回滚

1）先保存三条数据

2）开启一个事务，并往表中再插入三条数据

3）回滚事务

回滚事务后，发现新插入的三条数据消失了，数据库根据日志将三个操作回滚了，看起来好像和原来一样，其实是曾经写入过，只不过被擦除了

注意：

• 无论是 commit 还是rollback ，执行完毕后，刚刚记录的日志都会被自动删除掉
• 如果是已经提交过了，回滚就没有效果了

3.3 保存点

我们可以在事务执行过程中设置保存点（savepoint ），回滚时可以回滚到指定保存点的状态，但这些保存点会随着我们进行commit或者总体的回滚而消失

3.3.1 基本语法

*创建保存点
savepoint savepoint_name;

*回滚到某个保存点
rollback to savepoint_name;

3.3.2 示例

1）开始事务，并在插入数据的时候创建保存点

2）保存点回滚

4.事务的隔离性和隔离级别（超重点！！！）

4.1 隔离级别

就像地震有1级、2级一样，事务也有隔离级别，事务总共有四个隔离级别：read uncommitted（读未提交）、read committed（读已提交）、repetable read（可重复读）、serializable（串行化），越往后隔离性越强，接下来，我们将一一举例介绍

4.2 READ UNCOMMITTED（读未提交）与脏读

读未提交，在此隔离级别下，读取数据不做任何限制，并发性很高，但存在脏读问题，事务1先修改数据，但在未提交的情况下，会被事务2读取到，此时如果事务1进行回滚，那么事务2读取到的数据将是无效的，这就叫**" 脏读 "**

4.3 READ COMMITTED（读已提交）与不可重复读

为解决脏读，我们引入了READ COMMITTED（读已提交）的隔离级别，在此隔离级别下，事务只能读到其他事务提交之后的数据

但同时，READ COMMITTED（读已提交）会出现不可重复读问题，在同一个事务之内两次读取到的数据值不相同，这就好比你期末查成绩，早上查成绩100分，下午查成绩你挂科了，那不炸了 (σ｀д′)σ ！！

4.4 REPETABLE READ（可重复读）与幻读

为了解决不可重复读问题，我们就引入REPETABLE READ隔离级别，它依赖于MySQL内部的**" 快照机制 "**（后边有介绍），简单理解就是，事务开始时，数据库内部会进行一次数据的保存，此时外界的事务无论怎么修改，读取到的数据都是原来保存的那一份，直到事务结束，这就可以保证在同一个事务之内，多次读取到的数据都是一致的

MySQL的默认隔离级别 就是REPETABLE READ（可重复读），虽然这个隔离级别已经能解决绝大部分的问题了，但也不能说足够好，这个隔离级别有可能会出现 " 幻读 " 问题，即一个事务内，两次读取到的数据结果集不相同，可重复读这个隔离级别能够一定程度的解决 " 幻读 " 问题的，但在某些特殊情况下，仍会发生 " 幻读 "

4.5 SERALIZABLE（串行化）

如何能彻底处理幻读呢？此时就要引入我们第四个隔离级别SERALIZABLE（串行化） ，它可以从根本上解决 **" 幻读 "**问题，此时数据库内多个事务的执行，完全是串行执行的，即事务1执行完才可以执行事务2

在这个隔离级别下，数据的准确性是最高的，但执行事务的效率是最低的

4.6 事务的隔离性和并发性的关系

4.6.1 事务的隔离性和并发性的关系

事务的隔离性越强，并发性就越弱，效率越低，准确率越高；相反事务的隔离性越弱，并发性就越强，效率越高，准确性较低

拿我们写作业来类比，当我们在一个晚上需要完成全科的作业时，如果两项作业分别是数学和语文，两个不同学科，此时他们的隔离性就很强，就不能同时完成，并发性就很弱，我们需要分别分两段时间去做这两个不同学科的作业，效率就很低，但因为我们给每个事务都分配了独立的时间，在这个时间段只完成这科的作业，专注性提高，准确率就可以大大提高

4.6.2 不同隔离级别的性能与安全

下面由一张图来展示不同隔离级别的性能

4.7 查看和设置数据库的隔离级别

4.7.1 查看

我们可以通过下面这样的语句来查看我们此时的数据库的隔离级别

SELECT @@GLOBAL.transaction_isolation;

4.7.2 设置

设置的方式有以下两种，但都不需要去背，以后要用的时候查一下就可以了

*设置隔离级别
*方式一
SET GLOBAL transaction_isolation = 'SERIALIZABLE';
*方式二
SET @@GLOBAL.transaction_isolation='SERIALIZABLE';

注意：这样的设置方式只是临时生效，后续重启MySQL服务器，还是会失效，我们在实际开发中一般是通过 " 配置文件 " 的方式来进行修改的

5.问题汇总

5.1 InnoDB存储引擎

InnoDB 是 MySQL 最常用的存储引擎，它就像一个高效的事务处理管家，既能保证数据安全，又能扛住高并发访问

简单来说，它支持事务（ACID 特性）、行级锁、外键，还自带崩溃恢复能力，特别适合需要频繁更新或对数据一致性要求高的场景，比如电商、金融系统

可以把 InnoDB 想象成一个‌银行柜台‌：

• ‌事务‌就像一笔完整交易，要么全部完成，要么全部取消
• ‌行级锁‌是只锁定当前办理的窗口，其他窗口照常营业
• ‌外键‌像柜台间的协作规则，确保业务合规
• ‌崩溃恢复‌则是系统自动备份，意外中断后能快速恢复

5.2 数据库中的回滚与日志

数据库的回滚 机制和日志 是保证事务ACID特性的核心，简单来说，‌回滚机制‌负责撤销未完成的事务，确保数据一致性；而‌日志‌则是记录所有操作的关键，用于故障恢复和事务回滚

5.2.1 回滚机制

• Undo Log（回滚日志）‌：记录事务修改前的数据副本，用于回滚操作，保证原子性
• Redo Log（重做日志）‌：记录事务提交后的数据修改，用于崩溃恢复，保证持久性

5.2.2 日志类型

• Undo Log‌：记录逻辑操作，如INSERT、UPDATE、DELETE前的数据；用于事务回滚和多版本并发控制（MVCC）
• Redo Log‌：记录物理修改，如数据页的变更；采用WAL（Write-Ahead Logging）策略，事务提交前必须写入磁盘

5.2.3 实际应用

• 事务回滚‌：通过Undo Log撤销未提交的修改
• 崩溃恢复‌：通过Redo Log恢复已提交的事务
• MVCC‌：Undo Log支持多版本并发控制，提高并发性能

5.2.4 总结

• Undo Log‌：保证原子性和隔离性，用于回滚和MVCC
• Redo Log‌：保证持久性，用于崩溃恢复

这两者共同支撑了数据库的事务和恢复机制，是数据库稳定运行的基础

5.3 MySQL内部的快照机制

MySQL 的快照机制是 InnoDB 存储引擎 实现事务隔离的核心技术，它通过多版本并发控制（MVCC）来保证数据一致性，同时提升并发性能。简单来说，它让每个事务都能看到数据在某一时刻的 " 快照 " ，避免读写冲突

5.3.1 核心原理

• 多版本控制‌：每次更新数据时，旧版本会被保留，新版本会生成并关联到事务 ID
• 一致性视图‌：事务启动时，会创建一个 " 一致性视图 "，记录当前所有数据的版本号，确保读取的数据不受其他事务影响
• 快照读‌：在可重复读（RR）隔离级别下，事务启动时会立即创建快照，后续所有读取都基于这个快照，避免幻读

5.3.2 形象化比喻

可以把快照机制想象成‌图书馆的借阅系统‌：

• 多版本控制‌：每本书被借出时，系统会保留一个副本，新读者只能看到当前可用的版本
• 一致性视图‌：每个读者进入图书馆时，系统会记录当前所有书的版本号，确保他们看到的数据一致
• 快照读‌：在 RR 隔离级别下，读者进入图书馆时会立即拍一张快照，后续借阅都基于这张快照，避免看到其他读者借走后的变化

5.3.3 适用场景

• 高并发读取‌：如电商秒杀、社交平台，避免读写冲突
• 数据一致性要求高‌：如金融系统，确保事务隔离
• 报表分析‌：基于历史快照生成报表，不影响线上业务

5.3.4 注意事项

• 存储开销‌：旧版本数据会占用存储空间，需定期清理
• 隔离级别影响‌：不同隔离级别下快照的创建时机和可见性不同，需根据业务需求选择

5.4 API

**API（应用程序编程接口）**就是软件之间沟通的 " 桥梁 "，它定义了一套规则，让不同系统能安全、高效地共享数据和功能，而不用管对方内部怎么实现

5.4.1 核心作用

• 简化开发‌：比如用现成的支付接口，不用自己从头写代码
• 提升效率‌：像阿里云API能直接管理云资源，省去手动操作
• 保障安全‌：通过API Key等机制控制访问权限，防止滥用

5.4.2 常见类型

• Web API‌：基于HTTP协议，比如天气查询接口
• 本地API‌：操作系统或框架提供的接口，比如Windows API
• 远程API‌：支持跨网络调用，比如阿里云的RPC风格API

5.4.3 调用流程

• 查文档‌：了解接口怎么用
• 拿认证‌：申请API Key等身份凭证
• 发请求‌：构建URL、参数和请求头
• 收结果‌：处理返回的数据（通常是JSON或XML格式）

5.4.4 举个栗子

你手机上的天气App，就是通过API向服务器发请求，拿到数据再展示给你，整个过程你完全不用关心服务器怎么运作。

诸般往事，皆有利于我(●'◡'●)