【MySQL筑基篇】新手也能吃透的事务教程：ACID特性+Commit/Rollback实操指南

🍃 予枫：个人主页

📚 个人专栏: 《Java 从入门到起飞》《读研码农的干货日常》

💻 Debug 这个世界，Return 更好的自己！

引言

作为后端开发者，你是否遇到过这样的场景：用户A给用户B转账，钱从A账户扣了，B账户却没到账？这种数据不一致的问题，核心就在于没用好数据库事务。而事务的核心，正是ACID四大承诺。本文将用最经典的转账案例，拆解原子性、一致性、隔离性、持久性的定义，手把手演示COMMIT和ROLLBACK操作，新手也能轻松吃透！

文章目录

• 引言
• 一、什么是数据库事务？
• 二、ACID四大承诺：事务的核心保障
• • 2.1 原子性（Atomicity）：要么全成，要么全败
  • • 转账案例演示原子性
  • 2.2 一致性（Consistency）：数据始终合法
  • • 转账案例演示一致性
  • 2.3 隔离性（Isolation）：并行事务互不干扰
  • • 转账案例演示隔离性
  • 2.4 持久性（Durability）：提交后数据永久保存
  • • 转账案例演示持久性
• 三、COMMIT与ROLLBACK实操：用转账案例落地
• • 3.1 准备工作：创建账户表并插入数据
  • 3.2 手动控制事务：正常转账（COMMIT）
  • 3.3 手动控制事务：异常转账（ROLLBACK）
• 四、总结

一、什么是数据库事务？

数据库事务（Transaction），简单来说就是一组不可分割的数据库操作集合，这组操作要么全部执行成功，要么全部执行失败，不存在“部分成功”的情况。

举个通俗的例子：转账过程中，“扣减付款方余额”和“增加收款方余额”这两个操作，就构成了一个事务。要么两个操作都完成（转账成功），要么两个操作都回退（转账失败），绝对不能出现只扣钱没到账的情况。

💡 这里建议大家点赞收藏，后续遇到事务相关问题，随时可以回头查阅！

二、ACID四大承诺：事务的核心保障

ACID是事务的四大核心特性，分别对应原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。这四大特性共同保障了事务操作的数据安全性和一致性，缺一不可。

2.1 原子性（Atomicity）：要么全成，要么全败

原子性的核心是“不可分割”，事务中的所有操作作为一个整体，要么全部执行成功并提交，要么全部执行失败并回滚，没有中间状态。

转账案例演示原子性

假设用户A账户有1000元，用户B账户有500元，A给B转账200元，核心操作分为两步：

• 正常情况：两步操作都执行成功，事务提交（COMMIT），最终A有800元，B有700元。
• 异常情况：第一步执行成功（A剩800），第二步执行失败（比如数据库崩溃），此时事务必须回滚（ROLLBACK），A的余额恢复为1000元，B仍为500元，保证数据无差错。

2.2 一致性（Consistency）：数据始终合法

一致性指事务执行前后，数据库中的数据必须符合预设的业务规则和约束，保持数据的合法性和完整性。

转账案例演示一致性

延续上面的转账场景，业务规则是“所有用户账户余额总和保持不变”。

• 事务执行前：A（1000）+ B（500）= 1500元；
• 事务执行后（成功）：A（800）+ B（700）= 1500元；
• 事务执行后（失败回滚）：A（1000）+ B（500）= 1500元；

无论事务成功还是失败，数据总和始终符合业务规则，这就是一致性的体现。如果没有一致性保障，可能出现A扣了200，B只加了100的情况，导致总余额减少，违反业务约束。

2.3 隔离性（Isolation）：并行事务互不干扰

隔离性指多个事务同时并行执行时，每个事务的执行过程都像只有它自己在操作数据库一样，不会受到其他事务的干扰。

转账案例演示隔离性

假设同时有两个事务执行：

• 事务1：A给B转账200元；
• 事务2：查询A和B的账户余额总和；

在隔离性保障下，事务2要么查询到事务1执行前的总和（1500元），要么查询到事务1执行后的总和（1500元），不会查询到“A扣了200，B还没加200”的中间状态（此时总和为1300元），避免出现脏数据查询。

2.4 持久性（Durability）：提交后数据永久保存

持久性指事务一旦执行成功并提交（COMMIT），其对数据库的修改就会永久保存，即使之后数据库发生崩溃、重启等故障，修改的数据也不会丢失。

转账案例演示持久性

事务1执行成功并提交后，A的余额变为800元，B的余额变为700元。此时即使数据库突然崩溃，重启后再次查询，A和B的余额依然是800元和700元，不会恢复到转账前的状态。这就是持久性的核心价值——保障已提交事务的修改不丢失。

💡 看到这里，相信你已经对ACID四大特性有了清晰的理解！建议大家动手实操一下下面的代码，加深记忆~

三、COMMIT与ROLLBACK实操：用转账案例落地

在MySQL中，事务的默认隔离级别是REPEATABLE READ（可重复读），默认情况下事务是自动提交的（autocommit=1），我们可以通过手动控制事务，演示COMMIT和ROLLBACK的使用。

3.1 准备工作：创建账户表并插入数据

首先创建账户表account，包含用户ID和余额两个字段，然后插入A和B的初始数据：

— 创建账户表
CREATE TABLE IF NOT EXISTS account (
user_id VARCHAR(10) PRIMARY KEY,
balance INT NOT NULL DEFAULT 0
);

— 插入初始数据（A有1000，B有500）
INSERT INTO account (user_id, balance) VALUES ('A', 1000), ('B', 500);

3.2 手动控制事务：正常转账（COMMIT）

手动关闭自动提交，执行转账操作，然后提交事务：

— 关闭自动提交
SET autocommit = 0;

— 开启事务（可选，默认关闭autocommit后，第一条SQL语句自动开启事务）
START TRANSACTION;

— 步骤1：扣减A账户200元
UPDATE account SET balance = balance – 200 WHERE user_id = 'A';

— 步骤2：增加B账户200元
UPDATE account SET balance = balance + 200 WHERE user_id = 'B';

— 检查数据（此时数据未提交，仅在当前事务中可见）
SELECT * FROM account;

— 提交事务：永久保存修改
COMMIT;

— 重新开启自动提交（可选）
SET autocommit = 1;

执行上述代码后，再次查询account表，会发现A的余额为800，B的余额为700，转账成功，数据永久保存。

3.3 手动控制事务：异常转账（ROLLBACK）

模拟转账过程中出现异常，执行ROLLBACK回滚事务：

— 关闭自动提交
SET autocommit = 0;

— 开启事务
START TRANSACTION;

— 步骤1：扣减A账户200元
UPDATE account SET balance = balance – 200 WHERE user_id = 'A';

— 模拟异常：此处中断执行（比如代码报错、数据库崩溃）
— 步骤2：增加B账户200元（未执行）

— 检查数据（此时A的余额为600，B仍为700）
SELECT * FROM account;

— 回滚事务：撤销所有未提交的修改
ROLLBACK;

— 重新开启自动提交
SET autocommit = 1;

— 再次查询：数据恢复到事务执行前的状态（A=800，B=700）
SELECT * FROM account;

执行ROLLBACK后，所有未提交的修改都会被撤销，数据恢复到事务开启前的状态，完美体现了事务的原子性。

四、总结

本文通过经典的转账案例，详细拆解了数据库事务的ACID四大特性：原子性保障操作“要么全成要么全败”，一致性保障数据合法合规，隔离性保障并行事务互不干扰，持久性保障提交后数据不丢失。同时，通过MySQL实操代码，演示了COMMIT（提交事务）和ROLLBACK（回滚事务）的核心用法。

事务是数据库开发的基础，也是保障数据一致性的关键，无论是转账、订单创建还是用户注册等场景，都离不开事务的支持。掌握ACID特性和事务操作，是后端开发者的必备技能之一。