【MySQL筑基篇】新手也能吃透的事务教程：ACID特性+Commit/Rollback实操指南
引言
作为后端开发者，你是否遇到过这样的场景：用户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元，核心操作分为两步：
- 扣减A账户余额：UPDATE account SET balance = balance - 200 WHERE user_id = ‘A’;
- 增加B账户余额：UPDATE account SET balance = balance + 200 WHERE user_id = ‘B’;
- 正常情况：两步操作都执行成功，事务提交（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特性和事务操作，是后端开发者的必备技能之一。
本文地址：https://www.vps345.com/25120.html
