个人主页艾莉丝努力练剑❄专栏传送门《C语言》《数据结构与算法》《C/C干货分享学习过程记录》《Linux操作系统编程详解》《笔试/面试常见算法从基础到进阶》《Python干货分享》⭐️为天地立心为生民立命为往圣继绝学为万世开太平 艾莉丝的简介文章目录1 ~ 事务基础理论1.1 事务的定义1.2 设计背景与核心价值1.2.1 并发无控制的典型问题1.2.2 事务的核心价值1.3 ACID 四大特性1.3.1 原子性Atomicity1.3.2 一致性Consistency1.3.3 隔离性Isolation1.3.4 持久性Durability2 ~ MySQL 事务支持机制2.1 存储引擎支持2.1.1 查看引擎事务支持2.2 事务提交模式2.2.1 两种提交模式2.2.2 提交模式操作语法2.2.3 核心结论3 ~ 事务标准操作3.1 实验环境准备3.1.1 创建测试表3.1.2 设置隔离级别实验专用3.2 核心操作语法3.2.1 开启事务3.2.2 设置保存点3.2.3 事务回滚3.2.4 提交事务3.3 操作约束4 ~ 核心特性实验验证4.1 原子性验证4.1.1 场景 1未提交事务客户端异常崩溃4.1.2 场景 2保存点定向回滚4.2 持久性验证4.2.1 场景已提交事务客户端崩溃4.3 单条 SQL 与事务的关系4.3.1 核心结论4.3.2 对照验证5 ~ 事务隔离级别入门5.1 基本概念5.2 四大隔离级别5.2.1 读未提交Read Uncommitted5.2.2 读已提交Read Committed5.2.3 可重复读Repeatable Read5.2.4 串行化Serializable6 ~ 技术审计与勘误汇总6.1 概念性错误修正6.2 拼写与笔误修正6.3 表述准确性修正6.4 版本兼容性提示结尾1 ~ 事务基础理论1.1 事务的定义事务是由一条或多条逻辑相关的 DML 语句组成的执行集合该集合作为不可分割的整体要么全部执行成功要么全部执行失败并回滚对外呈现原子性的执行效果。业务视角将上层业务的一个完整操作如转账、购票映射为一组 SQL共同完成业务目标单条 SQL 脱离集合无独立业务意义。数据库视角MySQL 将一组 SQL 封装为事务对象进行调度管理保障并发场景下的数据正确性。1.2 设计背景与核心价值1.2.1 并发无控制的典型问题无事务保障的并发 CURD 会直接破坏数据一致性典型场景售票超卖多客户端同时读取库存为 1并发执行扣减最终同一张票被售卖两次。转账异常扣款操作执行后服务宕机收款方未到账数据库出现金额不守恒的中间状态。1.2.2 事务的核心价值事务本质是为应用层服务将并发控制、故障容错能力下沉到数据库层上层应用无需关心网络异常、服务宕机、并发冲突等底层问题。仅需关注业务逻辑通过提交 / 回滚即可保障数据正确性大幅简化编程模型。1.3 ACID 四大特性1.3.1 原子性Atomicity事务是不可分割的最小执行单元所有操作要么全部完成要么全部回滚到事务开始前的状态不存在部分执行的中间状态。实现依托回滚机制rollback事务执行异常时自动撤销已执行的所有操作。1.3.2 一致性Consistency事务执行前后数据库的完整性约束不被破坏数据始终符合预设的业务规则如账户余额总和不变、库存非负、主键唯一。关键说明一致性是事务的最终目标数据库通过原子性、隔离性、持久性共同保障一致性同时一致性依赖上层业务逻辑的正确性仅靠数据库无法完全保证。1.3.3 隔离性Isolation数据库支持多事务并发执行隔离性保障多个事务交叉执行时不会因互相干扰导致数据不一致。隔离性通过不同的隔离级别实现不同级别对应不同的并发干扰程度与性能表现。1.3.4 持久性Durability事务一旦提交commit对数据的修改就会永久持久化到磁盘后续即使系统宕机、服务重启已提交的数据也不会丢失。2 ~ MySQL 事务支持机制2.1 存储引擎支持MySQL 的事务能力由存储引擎层实现并非所有引擎都支持事务InnoDBMySQL 默认存储引擎完整支持事务、行级锁、外键同时支持保存点、XA 分布式事务。MyISAM、MEMORY、BLACKHOLE、CSV、ARCHIVE均不支持事务。2.1.1 查看引擎事务支持-- 横向展示所有引擎信息SHOWENGINES;-- 纵向展示便于阅读SHOWENGINES \G2.2 事务提交模式2.2.1 两种提交模式自动提交autocommit ONMySQL 默认模式单条 SQL 执行完成后自动提交事务用户无感知。手动提交通过begin显式开启事务必须执行commit才会提交执行rollback则回滚。2.2.2 提交模式操作语法-- 查看当前自动提交状态SHOWVARIABLESLIKEautocommit;-- 关闭自动提交SETAUTOCOMMIT0;-- 开启自动提交SETAUTOCOMMIT1;2.2.3 核心结论显式通过begin/start transaction开启的事务不受 autocommit 配置影响必须手动 commit 才会提交。未显式开启事务时单条 SQL 的行为由 autocommit 决定autocommitON 则自动提交autocommitOFF 则需手动提交。3 ~ 事务标准操作3.1 实验环境准备3.1.1 创建测试表CREATETABLEIFNOTEXISTSaccount(idINTPRIMARYKEY,nameVARCHAR(50)NOTNULLDEFAULT,balanceDECIMAL(10,2)NOTNULLDEFAULT0.0-- 原笔记blance为笔误修正为balance)ENGINEInnoDBDEFAULTCHARSETutf8;3.1.2 设置隔离级别实验专用为便于观察并发现象实验中将隔离级别设置为最低的读未提交-- 设置全局事务隔离级别为读未提交SETGLOBALTRANSACTIONISOLATIONLEVELREADUNCOMMITTED;-- MySQL 5.7 查询当前会话隔离级别SELECTtx_isolation;-- MySQL 8.0 查询当前会话隔离级别tx_isolation已废弃SELECTtransaction_isolation;注意修改全局隔离级别后需重启客户端会话才会生效。3.2 核心操作语法3.2.1 开启事务两种等价写法-- 写法1STARTTRANSACTION;-- 写法2推荐更简洁BEGIN;3.2.2 设置保存点用于实现事务内的定向回滚一个事务可设置多个保存点SAVEPOINT保存点名称;-- 示例SAVEPOINTs1;3.2.3 事务回滚两种回滚粒度-- 1. 回滚到指定保存点撤销保存点之后的所有操作ROLLBACKTO保存点名称;-- 示例ROLLBACKTOs1;-- 2. 回滚整个事务撤销事务内所有操作回到事务初始状态ROLLBACK;3.2.4 提交事务COMMIT;3.3 操作约束未设置保存点时rollback直接回滚到事务开启时的状态。事务一旦执行commit提交就无法再回滚。保存点仅在当前事务内有效事务提交或全量回滚后保存点自动失效。4 ~ 核心特性实验验证4.1 原子性验证4.1.1 场景 1未提交事务客户端异常崩溃操作步骤开启事务 → 执行 INSERT/UPDATE 等 DML → 不执行 commit直接强制终止客户端进程。实验现象重启客户端后查询数据不存在MySQL 自动回滚了未提交的事务。结论未提交的事务异常终止时数据库自动回滚所有修改保障无中间状态体现原子性。4.1.2 场景 2保存点定向回滚操作步骤开启事务 → 设置保存点 s1 → 插入数据 → 设置保存点 s2 → 插入第二条数据 → 回滚到 s1。实验现象第二条数据被撤销仅保留 s1 之前的操作。结论事务支持粒度化的回滚能力是原子性的具体实现形式。4.2 持久性验证4.2.1 场景已提交事务客户端崩溃操作步骤开启事务 → 执行 DML → 执行 commit 提交 → 强制终止客户端进程。实验现象重启客户端后查询数据依然存在。结论事务提交后修改已持久化到磁盘客户端崩溃、服务重启都不会丢失数据体现持久性。4.3 单条 SQL 与事务的关系4.3.1 核心结论InnoDB 中所有 SQL 操作本质都属于事务日常单条 SQL 无事务感知是因为autocommitON时 SQL 执行完自动提交了事务。4.3.2 对照验证autocommit OFF 场景执行单条 DELETE 后不 commit客户端崩溃数据自动回滚。本质单条 SQL 开启了事务但未提交异常触发回滚机制。autocommit ON 场景执行单条 DELETE 后客户端崩溃数据已被永久删除。本质单条 SQL 执行完毕后自动提交事务修改已持久化。5 ~ 事务隔离级别入门5.1 基本概念隔离性保障多事务并发执行时互不干扰、数据一致的能力。隔离级别定义了事务之间的干扰程度级别越低并发性能越高但数据一致性越差。5.2 四大隔离级别5.2.1 读未提交Read Uncommitted定义一个事务可以读取到其他事务未提交的修改结果。并发问题脏读、不可重复读、幻读。应用生产环境基本不使用仅用于原理演示实验。5.2.2 读已提交Read Committed定义一个事务只能读取到其他事务已经提交的修改。并发问题解决了脏读但存在不可重复读同一事务内多次 SELECT 同一行结果不一致。应用大多数数据库的默认隔离级别如 Oracle、PostgreSQL。5.2.3 可重复读Repeatable Read定义同一事务内多次读取同一行数据结果始终一致。并发问题解决了脏读、不可重复读理论上存在幻读InnoDB 通过 MVCC 间隙锁在很大程度上解决了幻读问题。应用MySQL 的默认隔离级别。5.2.4 串行化Serializable定义最高隔离级别强制事务串行执行对读取的数据行加共享锁。并发问题解决了所有并发异常但性能极差会导致大量锁竞争和超时。应用生产环境极少使用。6 ~ 技术审计与勘误汇总6.1 概念性错误修正原文错误表述修正后正确表述原子性、隔离性、持久性这三个是 “因”原子性是 “果”原子性、隔离性、持久性这三个是 “因”一致性是 “果”数据库通过实现前三者保障一致性6.2 拼写与笔误修正erializable→Serializable串行化英文拼写blance→balance账户余额字段MtISAM→MyISAM存储引擎名称6.3 表述准确性修正原文“对于 InnoDB 每一条 SQL 语言都默认封装成事务自动提交。(select 有特殊情况因为 MySQL 有 MVCC)”修正InnoDB 中所有单条 SQL 在autocommitON时都会被封装为独立事务并自动提交包含 SELECT 语句。MVCC 是事务隔离的实现机制并非让 SELECT 脱离事务的原因。6.4 版本兼容性提示tx_isolation仅适用于 MySQL 5.7 及更早版本MySQL 8.0 已移除该变量统一使用transaction_isolation查询事务隔离级别。结尾uu们本文的内容到这里就全部结束了艾莉丝在这里再次感谢您的阅读艾莉丝努力练剑C/C Linux 底层探索者 | 一个正在努力练剑的技术博主【关注】跟随我一起深耕技术领域见证每一次成长。❤️【点赞】让优质内容被更多人看见让知识传递更有力量。⭐【收藏】把核心知识点存好在需要时随时查、随时用。【评论】分享你的经验或疑问评论区一起交流避坑不要忘记给博主“一键四连”哦“今日练剑达成”“技术之路难免有困惑但同行的人会让前进更有方向。”结语希望对学习Linux相关内容的uu有所帮助不要忘记给博主“一键四连”哦往期回顾【MYSQL】MYSQL学习的一大重点索引下- B树博主在这里放了一只小狗大家看完了摸摸小狗放松一下吧૮₍ ˶ ˊ ᴥ ˋ˶₎ა 【MYSQL】MYSQL学习的一大重点：事务（上）- 原子性与持久性
个人主页艾莉丝努力练剑❄专栏传送门《C语言》《数据结构与算法》《C/C干货分享学习过程记录》《Linux操作系统编程详解》《笔试/面试常见算法从基础到进阶》《Python干货分享》⭐️为天地立心为生民立命为往圣继绝学为万世开太平 艾莉丝的简介文章目录1 ~ 事务基础理论1.1 事务的定义1.2 设计背景与核心价值1.2.1 并发无控制的典型问题1.2.2 事务的核心价值1.3 ACID 四大特性1.3.1 原子性Atomicity1.3.2 一致性Consistency1.3.3 隔离性Isolation1.3.4 持久性Durability2 ~ MySQL 事务支持机制2.1 存储引擎支持2.1.1 查看引擎事务支持2.2 事务提交模式2.2.1 两种提交模式2.2.2 提交模式操作语法2.2.3 核心结论3 ~ 事务标准操作3.1 实验环境准备3.1.1 创建测试表3.1.2 设置隔离级别实验专用3.2 核心操作语法3.2.1 开启事务3.2.2 设置保存点3.2.3 事务回滚3.2.4 提交事务3.3 操作约束4 ~ 核心特性实验验证4.1 原子性验证4.1.1 场景 1未提交事务客户端异常崩溃4.1.2 场景 2保存点定向回滚4.2 持久性验证4.2.1 场景已提交事务客户端崩溃4.3 单条 SQL 与事务的关系4.3.1 核心结论4.3.2 对照验证5 ~ 事务隔离级别入门5.1 基本概念5.2 四大隔离级别5.2.1 读未提交Read Uncommitted5.2.2 读已提交Read Committed5.2.3 可重复读Repeatable Read5.2.4 串行化Serializable6 ~ 技术审计与勘误汇总6.1 概念性错误修正6.2 拼写与笔误修正6.3 表述准确性修正6.4 版本兼容性提示结尾1 ~ 事务基础理论1.1 事务的定义事务是由一条或多条逻辑相关的 DML 语句组成的执行集合该集合作为不可分割的整体要么全部执行成功要么全部执行失败并回滚对外呈现原子性的执行效果。业务视角将上层业务的一个完整操作如转账、购票映射为一组 SQL共同完成业务目标单条 SQL 脱离集合无独立业务意义。数据库视角MySQL 将一组 SQL 封装为事务对象进行调度管理保障并发场景下的数据正确性。1.2 设计背景与核心价值1.2.1 并发无控制的典型问题无事务保障的并发 CURD 会直接破坏数据一致性典型场景售票超卖多客户端同时读取库存为 1并发执行扣减最终同一张票被售卖两次。转账异常扣款操作执行后服务宕机收款方未到账数据库出现金额不守恒的中间状态。1.2.2 事务的核心价值事务本质是为应用层服务将并发控制、故障容错能力下沉到数据库层上层应用无需关心网络异常、服务宕机、并发冲突等底层问题。仅需关注业务逻辑通过提交 / 回滚即可保障数据正确性大幅简化编程模型。1.3 ACID 四大特性1.3.1 原子性Atomicity事务是不可分割的最小执行单元所有操作要么全部完成要么全部回滚到事务开始前的状态不存在部分执行的中间状态。实现依托回滚机制rollback事务执行异常时自动撤销已执行的所有操作。1.3.2 一致性Consistency事务执行前后数据库的完整性约束不被破坏数据始终符合预设的业务规则如账户余额总和不变、库存非负、主键唯一。关键说明一致性是事务的最终目标数据库通过原子性、隔离性、持久性共同保障一致性同时一致性依赖上层业务逻辑的正确性仅靠数据库无法完全保证。1.3.3 隔离性Isolation数据库支持多事务并发执行隔离性保障多个事务交叉执行时不会因互相干扰导致数据不一致。隔离性通过不同的隔离级别实现不同级别对应不同的并发干扰程度与性能表现。1.3.4 持久性Durability事务一旦提交commit对数据的修改就会永久持久化到磁盘后续即使系统宕机、服务重启已提交的数据也不会丢失。2 ~ MySQL 事务支持机制2.1 存储引擎支持MySQL 的事务能力由存储引擎层实现并非所有引擎都支持事务InnoDBMySQL 默认存储引擎完整支持事务、行级锁、外键同时支持保存点、XA 分布式事务。MyISAM、MEMORY、BLACKHOLE、CSV、ARCHIVE均不支持事务。2.1.1 查看引擎事务支持-- 横向展示所有引擎信息SHOWENGINES;-- 纵向展示便于阅读SHOWENGINES \G2.2 事务提交模式2.2.1 两种提交模式自动提交autocommit ONMySQL 默认模式单条 SQL 执行完成后自动提交事务用户无感知。手动提交通过begin显式开启事务必须执行commit才会提交执行rollback则回滚。2.2.2 提交模式操作语法-- 查看当前自动提交状态SHOWVARIABLESLIKEautocommit;-- 关闭自动提交SETAUTOCOMMIT0;-- 开启自动提交SETAUTOCOMMIT1;2.2.3 核心结论显式通过begin/start transaction开启的事务不受 autocommit 配置影响必须手动 commit 才会提交。未显式开启事务时单条 SQL 的行为由 autocommit 决定autocommitON 则自动提交autocommitOFF 则需手动提交。3 ~ 事务标准操作3.1 实验环境准备3.1.1 创建测试表CREATETABLEIFNOTEXISTSaccount(idINTPRIMARYKEY,nameVARCHAR(50)NOTNULLDEFAULT,balanceDECIMAL(10,2)NOTNULLDEFAULT0.0-- 原笔记blance为笔误修正为balance)ENGINEInnoDBDEFAULTCHARSETutf8;3.1.2 设置隔离级别实验专用为便于观察并发现象实验中将隔离级别设置为最低的读未提交-- 设置全局事务隔离级别为读未提交SETGLOBALTRANSACTIONISOLATIONLEVELREADUNCOMMITTED;-- MySQL 5.7 查询当前会话隔离级别SELECTtx_isolation;-- MySQL 8.0 查询当前会话隔离级别tx_isolation已废弃SELECTtransaction_isolation;注意修改全局隔离级别后需重启客户端会话才会生效。3.2 核心操作语法3.2.1 开启事务两种等价写法-- 写法1STARTTRANSACTION;-- 写法2推荐更简洁BEGIN;3.2.2 设置保存点用于实现事务内的定向回滚一个事务可设置多个保存点SAVEPOINT保存点名称;-- 示例SAVEPOINTs1;3.2.3 事务回滚两种回滚粒度-- 1. 回滚到指定保存点撤销保存点之后的所有操作ROLLBACKTO保存点名称;-- 示例ROLLBACKTOs1;-- 2. 回滚整个事务撤销事务内所有操作回到事务初始状态ROLLBACK;3.2.4 提交事务COMMIT;3.3 操作约束未设置保存点时rollback直接回滚到事务开启时的状态。事务一旦执行commit提交就无法再回滚。保存点仅在当前事务内有效事务提交或全量回滚后保存点自动失效。4 ~ 核心特性实验验证4.1 原子性验证4.1.1 场景 1未提交事务客户端异常崩溃操作步骤开启事务 → 执行 INSERT/UPDATE 等 DML → 不执行 commit直接强制终止客户端进程。实验现象重启客户端后查询数据不存在MySQL 自动回滚了未提交的事务。结论未提交的事务异常终止时数据库自动回滚所有修改保障无中间状态体现原子性。4.1.2 场景 2保存点定向回滚操作步骤开启事务 → 设置保存点 s1 → 插入数据 → 设置保存点 s2 → 插入第二条数据 → 回滚到 s1。实验现象第二条数据被撤销仅保留 s1 之前的操作。结论事务支持粒度化的回滚能力是原子性的具体实现形式。4.2 持久性验证4.2.1 场景已提交事务客户端崩溃操作步骤开启事务 → 执行 DML → 执行 commit 提交 → 强制终止客户端进程。实验现象重启客户端后查询数据依然存在。结论事务提交后修改已持久化到磁盘客户端崩溃、服务重启都不会丢失数据体现持久性。4.3 单条 SQL 与事务的关系4.3.1 核心结论InnoDB 中所有 SQL 操作本质都属于事务日常单条 SQL 无事务感知是因为autocommitON时 SQL 执行完自动提交了事务。4.3.2 对照验证autocommit OFF 场景执行单条 DELETE 后不 commit客户端崩溃数据自动回滚。本质单条 SQL 开启了事务但未提交异常触发回滚机制。autocommit ON 场景执行单条 DELETE 后客户端崩溃数据已被永久删除。本质单条 SQL 执行完毕后自动提交事务修改已持久化。5 ~ 事务隔离级别入门5.1 基本概念隔离性保障多事务并发执行时互不干扰、数据一致的能力。隔离级别定义了事务之间的干扰程度级别越低并发性能越高但数据一致性越差。5.2 四大隔离级别5.2.1 读未提交Read Uncommitted定义一个事务可以读取到其他事务未提交的修改结果。并发问题脏读、不可重复读、幻读。应用生产环境基本不使用仅用于原理演示实验。5.2.2 读已提交Read Committed定义一个事务只能读取到其他事务已经提交的修改。并发问题解决了脏读但存在不可重复读同一事务内多次 SELECT 同一行结果不一致。应用大多数数据库的默认隔离级别如 Oracle、PostgreSQL。5.2.3 可重复读Repeatable Read定义同一事务内多次读取同一行数据结果始终一致。并发问题解决了脏读、不可重复读理论上存在幻读InnoDB 通过 MVCC 间隙锁在很大程度上解决了幻读问题。应用MySQL 的默认隔离级别。5.2.4 串行化Serializable定义最高隔离级别强制事务串行执行对读取的数据行加共享锁。并发问题解决了所有并发异常但性能极差会导致大量锁竞争和超时。应用生产环境极少使用。6 ~ 技术审计与勘误汇总6.1 概念性错误修正原文错误表述修正后正确表述原子性、隔离性、持久性这三个是 “因”原子性是 “果”原子性、隔离性、持久性这三个是 “因”一致性是 “果”数据库通过实现前三者保障一致性6.2 拼写与笔误修正erializable→Serializable串行化英文拼写blance→balance账户余额字段MtISAM→MyISAM存储引擎名称6.3 表述准确性修正原文“对于 InnoDB 每一条 SQL 语言都默认封装成事务自动提交。(select 有特殊情况因为 MySQL 有 MVCC)”修正InnoDB 中所有单条 SQL 在autocommitON时都会被封装为独立事务并自动提交包含 SELECT 语句。MVCC 是事务隔离的实现机制并非让 SELECT 脱离事务的原因。6.4 版本兼容性提示tx_isolation仅适用于 MySQL 5.7 及更早版本MySQL 8.0 已移除该变量统一使用transaction_isolation查询事务隔离级别。结尾uu们本文的内容到这里就全部结束了艾莉丝在这里再次感谢您的阅读艾莉丝努力练剑C/C Linux 底层探索者 | 一个正在努力练剑的技术博主【关注】跟随我一起深耕技术领域见证每一次成长。❤️【点赞】让优质内容被更多人看见让知识传递更有力量。⭐【收藏】把核心知识点存好在需要时随时查、随时用。【评论】分享你的经验或疑问评论区一起交流避坑不要忘记给博主“一键四连”哦“今日练剑达成”“技术之路难免有困惑但同行的人会让前进更有方向。”结语希望对学习Linux相关内容的uu有所帮助不要忘记给博主“一键四连”哦往期回顾【MYSQL】MYSQL学习的一大重点索引下- B树博主在这里放了一只小狗大家看完了摸摸小狗放松一下吧૮₍ ˶ ˊ ᴥ ˋ˶₎ა