一、引言

在后端开发、系统架构设计与面试场景中，MySQL事务隔离级别与Redis事务、持久化机制是数据库体系的两大核心重难点。二者分别代表了关系型数据库强一致性设计与缓存数据库高性能设计的典型思想。

⭐很多开发者学习时容易将两者割裂：熟练掌握MySQL事务ACID，却不清楚Redis事务不支持回滚的特性；了解RDB/AOF持久化，却无法对比MySQL Redo Log与Redis持久化的设计取舍。

本文将以对比视角贯穿全文，从事务基础、隔离机制、锁策略、持久化方案四个维度，全方位拆解 MySQL 与 Redis 的核心差异，帮你建立「关系型数据库+缓存数据库」的完整事务与数据可靠性知识体系。

二、MySQL事务隔离级别

1. 事务基础操作

MySQL 事务是保证数据一致性的核心，支持完整 ACID 特性，核心操作命令如下：

• BEGIN/ START TRANSACTION：手动开启事务

• COMMIT：提交事务，所有修改持久化生效

• ROLLBACK：回滚事务，撤销所有未提交修改

MySQL 默认开启autocommit=ON，每条SQL自动提交、独立事务。手动开启事务后，autocommit 临时失效，必须主动执行 COMMIT/ROLLBACK 结束事务。

# 开启事务 BEGIN; # 执行数据修改 UPDATE user SET age = 20 WHERE id = 1; # 回滚撤销修改 ROLLBACK; # 手动提交事务 COMMIT;

2. 四种隔离级别详解（由低到高）

事务并发会引发三大问题：脏读、不可重复读、幻读。MySQL InnoDB 提供四种隔离级别，逐级解决并发问题，代价是牺牲并发性能。

注意：并非所有的数据库能支持事务，MYSQL中的innoDB引擎支持，但是MyISAM不支持

核心现象SQL演示

脏读：一个事务读取到另一个事务未提交的修改数据，对方回滚后数据失效。

不可重复读：同一事务内，两次查询同一数据，结果被其他已提交事务修改，前后不一致。

幻读：同一事务内，范围查询结果被其他事务插入/删除数据，结果行数不一致，出现“凭空多出/减少数据”的幻觉。

3. 隔离级别查看与修改命令

MySQL 不同版本查询语法略有差异，支持会话级、全局级修改。

查看当前会话隔离级别（MySQL8.0）：

SELECT @@transaction_isolation;

查看当前会话隔离级别（MySQL5.7）：

SELECT @@tx_isolation;

查看全局隔离级别：

SELECT @@global.transaction_isolation;

修改隔离级别：

修改当前会话隔离级别：

set session transaction isolation level +隔离级别

修改全局隔离级别：

set global transaction isolation level +隔离级别

# 修改当前会话隔离级别为读已提交 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; # 修改全局隔离级别（重启生效） SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;

4. MySQL事务核心小结

MySQL InnoDB 事务是强一致性事务：完全满足 ACID 特性，支持事务回滚，通过 MVCC、行锁、间隙锁、临键锁组合实现四种隔离级别，兼顾并发性能与数据一致性，是复杂业务、核心交易系统的基石。

三、Redis事务深度解析

1. Redis事务基础操作

Redis 事务的核心逻辑是：命令入队、批量执行、无中间阻塞，核心三命令：

• MULTI：开启事务，后续命令进入事务队列排队

• EXEC：执行队列中所有命令，结束事务

• DISCARD：放弃事务，清空命令队列，不执行任何操作

实操示例：

127.0.0.1:6379> MULTI OK 127.0.0.1:6379> SET name redis_tx QUEUED 127.0.0.1:6379> SET age 6 QUEUED 127.0.0.1:6379> EXEC 1) OK 2) OK

2. Redis事务核心特性

Redis 事务与MySQL事务本质不同，核心两大特性：

1. 不支持原子回滚（核心区别）：Redis 事务不满足严格原子性，队列中部分命令执行失败，不会回滚已执行成功的命令，剩余合法命令继续执行。

2. 串行隔离执行：事务从 EXEC 开始执行到结束的全过程，是单线程串行执行，不会被其他客户端命令插队，保证执行隔离性。

3. 事务两类错误处理机制

Redis 事务错误分为语法错误和运行时错误，处理逻辑完全不同，是高频面试考点。

核心结论：Redis 设计者为极致高性能，放弃了事务回滚能力，认为语法错误是开发编码问题、运行时业务错误需业务层规避，无需数据库层面兜底。

4. Redis乐观锁：WATCH 机制

Redis 无悲观锁，通过WATCH 命令实现 CAS 乐观锁，解决高并发资源竞争问题（典型场景：秒杀库存扣减）。

乐观锁：假设操作不会发生冲突，不加锁直接操作，提交时检查是否被修改

场景：读多写少，冲突概率低，追求高性能
悲观锁：假设任何操作都会发生冲突，操作数据前先加锁，阻塞其他操作

场景：写多读少，冲突概率高，数据的一致性要求严格

执行原理

WATCH 监控指定 key→MULTI 开启事务入队→EXEC 执行时校验 key 是否被其他客户端修改→若被修改，事务直接失效返回 nil，无任何执行；未被修改则正常执行。

秒杀库存实操案例

# 初始化库存 127.0.0.1:6379> SET stock 10 OK # 监控库存key 127.0.0.1:6379> WATCH stock OK # 开启事务扣减库存 127.0.0.1:6379> MULTI OK 127.0.0.1:6379> DECR stock QUEUED # 此时另一客户端修改stock，当前客户端EXEC返回nil，事务失败 127.0.0.1:6379> EXEC (nil)

支持批量监控：WATCH 可同时监听多个 key，任意一个key被修改，事务全部失效，完美实现 CAS 无锁并发控制。

5. Redis事务 vs MySQL事务 核心对比

四、Redis持久化机制：RDB 与 AOF

1. 持久化核心意义

Redis 是纯内存数据库，所有数据常驻内存，进程退出、服务器断电、重启后内存数据全部丢失。持久化的核心目的：将内存数据落地磁盘，实现数据备份与故障恢复，保障数据可靠性。

2. RDB（全量快照）

本质：定期给内存数据拍完整快照，生成二进制dump.rdb文件，属于全量备份。

触发方式

• 手动触发：SAVE（阻塞主进程，不推荐）、BGSAVE（fork子进程后台执行，生产推荐）

• 自动触发：配置 save [秒数] [修改次数]，例：save 900 1代表900秒内有1次数据修改即触发快照

核心执行流程（COW写时复制）

1. 主进程接收 BGSAVE 指令，调用 fork() 创建子进程；

2. 依托Copy-On-Write 写时复制技术，父子进程共享内存页表，无数据拷贝开销；

3. 子进程遍历内存数据，写入临时 RDB 文件；

4. 写入完成后，原子替换旧 dump.rdb 文件，主进程全程正常处理业务请求。

📕fork创建子进程采用写时复制(COW)，父子进程初始共享物理页面，页面设为只读。COW复制粒度为内存页而非单个变量。任意进程修改页内数据时触发缺页异常，操作系统完整复制整页，执行修改的进程映射切换至新物理页。跨页面时，仅修改所在页面复制，其余页面继续共享。线程无COW机制。

RDB 优缺点

✅ 优点：文件紧凑体积小、灾难恢复速度快（直接加载二进制文件）、后台执行对主线程影响小、适合冷备份

❌ 缺点：存在数据丢失窗口（两次快照间数据断电丢失）、数据量大时，子进程运行时间过长，且fork时内存占用翻倍不能实时持久化

3. AOF（增量日志）

本质：以日志追加形式，记录每一条写操作命令（SET/INCR/LPUSH等），生成appendonly.aof日志文件，属于增量备份。

核心机制：AOF 重写

长期追加命令会导致AOF文件无限膨胀，Redis 自动触发重写机制，精简日志：

• auto-aof-rewrite-percentage 100：文件体积较上次重写增长100%触发重写

• auto-aof-rewrite-min-size 64mb：文件最小64MB才触发重写

• BGREWRITEAOF：手动触发重写，生成最简命令日志，剔除无效冗余命令

AOF 优缺点

✅ 优点：支持秒级/实时持久化、数据丢失极少、日志可读、安全性极高

❌ 缺点：文件体积大、重启恢复需重放所有命令速度慢、频繁写盘损耗性能

4. RDB 与 AOF 全方位对比

5. 生产环境最佳实践

Redis4.0+ 推荐混合持久化：RDB 全量快照 + AOF 增量日志，兼顾两大优势：

• Redis 重启永远优先加载 AOF 文件，无AOF文件时才加载独立 RDB 文件。

• 开启 Redis4.0+ 混合持久化后，AOF 重写生成的文件为特殊混合结构：文件头部是标准 RDB 二进制全量快照、文件尾部是 AOF 文本增量命令，实现“二进制快照快速打底 + 增量命令补全”的高效恢复；

• 生产环境同时开启RDB+AOF，AOF优先级高于RDB，最大化保障数据安全与恢复效率。

Redis重启 │ ▼ 检查是否存在AOF文件？ │ ├── 存在 → 加载AOF文件 │ │ │ ├── 读取RDB头部（二进制） → 快速加载全量数据 │ └── 读取AOF尾部（文本） → 重放增量命令 │ └── 不存在 → 加载RDB文件（传统方式）

五、乐观锁 vs 悲观锁 深度对比

MySQL 以悲观锁为主、MVCC乐观锁为辅；Redis 仅支持 WATCH 乐观锁，二者是并发控制的两种核心思想。

六、MySQL vs Redis 事务与持久化 终极总结

核心设计取舍：MySQL 牺牲部分性能，换取数据绝对一致、事务绝对可靠；Redis 牺牲严格事务一致性，换取极致并发性能、低延迟响应。

七、生产实践建议与高频面试题

1. 生产环境选型建议

• 金融交易、账务结算：选用 MySQL，隔离级别配置 REPEATABLE READ (可重复读)或 SERIALIZABLE（串行化），依托完整事务保障数据一致。

• 秒杀、库存扣减、高并发缓存：选用 Redis + WATCH 乐观锁，依托高性能、无阻塞特性承载大流量。

• 会话缓存、临时数据：仅开启 RDB 即可，兼顾性能与基础数据备份。

• 核心业务缓存数据：开启 Redis 混合持久化，兼顾恢复速度与数据安全。

2. 高频面试题

Q1：MySQL 的 REPEATABLE READ 如何解决幻读？

MySQL InnoDB 在可重复读隔离级别下，通过MVCC乐观锁多版本并发控制 + Next-Key临键锁组合解决幻读问题：快照读依靠MVCC读取事务启动时的一致性视图，规避新增数据带来的幻读；当前读（UPDATE/DELETE/SELECT FOR UPDATE）依靠Next-Key锁（行锁+间隙锁）锁定数据及插入间隙，禁止其他事务插入新数据，从工程层面彻底解决幻读。

Q2：Redis 事务为什么不支持回滚？

Redis 设计哲学为极致高性能优先。开发者认为：语法错误属于编码问题，应在开发阶段修复；运行时逻辑错误属于业务问题，应由业务层处理。舍弃事务回滚机制，大幅简化底层实现、减少锁与日志开销，最大化提升并发性能。

Q3：RDB 的 COW 写时复制机制原理？

执行BGSAVE时，主进程 fork 子进程，父子进程初始共享同一份内存页表。当主进程处理新的写请求，修改内存数据时，才会复制对应内存页，保证子进程快照数据完整、不被修改，同时最大程度降低内存与性能开销。

Q4：Redis 断电后如何恢复数据？

Redis 重启时自动加载持久化文件：优先加载 AOF 文件（数据更完整），无AOF则加载 RDB 快照文件，通过落地磁盘的日志/快照恢复断电前数据。

生产混合持久化模式下，会结合RDB基础快照+AOF增量日志完整恢复数据。

八、结尾总结

MySQL 与 Redis 的事务、持久化差异，本质是一致性与性能的终极权衡。关系型数据库以数据可靠、事务严谨为核心，缓存数据库以高并发、低延迟为首要目标。

建议大家在 Linux 环境动手实操：搭建双会话测试MySQL四大隔离级别的脏读/不可重复读/幻读现象，通过双 redis-cli 模拟 WATCH 秒杀并发冲突、手动触发 RDB/AOF 持久化，理论结合实操才能彻底吃透核心原理。

互动提问：你在生产环境中遇到过事务隔离级别配置不当、Redis持久化异常导致的数据问题吗？欢迎评论区交流！