事务的五大状态

        事务是数据库操作中的核心概念，对应一个或多个数据库操作（如 DML 语句）。MySQL 根据操作执行的不同阶段，将事务划分为活动的、部分提交的、失败的、中止的、提交的五种核心状态，各状态的触发条件、特征及转换逻辑如下：

1. 活动的（Active）：事务执行中状态

• 定义：事务对应的所有数据库操作正在执行过程中，尚未结束时，事务处于 “活动的” 状态。这是事务的初始执行状态。
• 核心特征：操作正在内存中逐步执行，尚未产生最终结果，也未对磁盘数据造成不可逆影响。

2. 部分提交的（Partially Committed）：执行完成但未持久化状态

• 定义：事务中的最后一个数据库操作已执行完成，但所有操作的结果仅保存在内存中，尚未同步（刷新）到磁盘时，事务处于 “部分提交的” 状态。
• 核心特征：逻辑上事务已执行完毕，但数据仍停留在内存缓冲区（如 MySQL 的 Buffer Pool），未写入磁盘文件（如 InnoDB 的数据文件），此时数据存在丢失风险.
• 示例：转账事务的UPDATE语句均已执行完成，但未执行COMMIT（或数据库未自动将内存数据刷盘），此时事务处于部分提交状态。

3. 失败的（Failed）：事务无法继续执行的异常状态

• 定义：事务在 “活动的” 或 “部分提交的” 状态下，因错误或外力干预无法继续执行时，进入 “失败的” 状态。
• 触发场景：
  • 数据库自身错误：如 SQL 语法错误、主键冲突、锁超时等。
  • 系统级错误：如操作系统崩溃、服务器断电、磁盘损坏等。
  • 人为干预：如手动执行ROLLBACK中断事务。
• 核心特征：事务执行中断，未达成预期目标，且可能已对内存数据造成部分修改。
• 示例：转账事务执行到第二条UPDATE语句时，服务器突然断电；或执行过程中因 “余额不足” 触发业务报错，事务均会进入失败状态。

4. 中止的（Aborted）：事务回滚后的恢复状态

• 定义：当事务处于 “失败的” 状态时，需通过 “回滚（Rollback）” 操作撤销其已对数据库造成的所有修改，将数据恢复到事务执行前的初始状态。回滚操作执行完毕后，事务进入 “中止的” 状态。
• 核心逻辑：“回滚” 是数据库保证事务原子性（要么全做，要么全不做）的关键操作，它会撤销失败事务中所有已执行的修改（如将 AA 减少的 50 元加回、BB 增加的 50 元减去）。
• 核心特征：数据库状态完全恢复到事务开始前，事务对数据的所有影响被清除，事务生命周期结束（中止状态是事务的 “终态” 之一）。
• 示例：转账事务因断电进入失败状态，服务器重启后，数据库自动执行回滚，将 AA 和 BB 的余额恢复到转账前的数值，回滚完成后，事务处于中止状态。

5. 提交的（Committed）：事务持久化后的完成状态

• 定义：当事务处于 “部分提交的” 状态时，若将内存中修改后的数据成功同步到磁盘（即完成持久化），事务进入 “提交的” 状态。
• 核心特征：
  • 数据持久化：修改后的数据写入磁盘，即使后续发生断电、重启，数据也不会丢失。
  • 事务完成：达成预期业务目标（如转账成功），事务生命周期结束（提交状态是事务的另一个 “终态”）。
• 触发方式：
  • 显式提交：执行COMMIT语句，数据库主动将内存数据刷盘。
  • 隐式提交：如执行CREATE TABLE、DROP TABLE等 DDL 语句时，数据库会自动提交事务。

事务状态转换流程图