MySQL事务隔离级别共四种，从低到高为读未提交、读已提交、可重复读（默认）、串行化，分别解决脏读、不可重复读、幻读问题：RU存在全部三类问题；RC解决脏读但残留后两者；RR解决前两者并借助间隙锁+临键锁大幅规避幻读；Serializable彻底解决三者但并发归零。
MySQL 事务隔离级别共四种，按隔离强度从低到高依次是：读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）、串行化（Serializable）。它们的核心作用是在并发场景下平衡数据一致性与系统性能，通过不同机制解决三类典型并发读问题：脏读、不可重复读、幻读。
一、四种隔离级别分别解决什么问题？
读未提交（RU）
允许读取其他事务尚未提交的数据。
❌ 存在脏读、不可重复读、幻读 —— 实际生产中基本不用。读已提交（RC）
只能读到其他事务已提交后的数据。
✅ 解决脏读；❌ 仍存在不可重复读、幻读。
常见于 Oracle，默认不保证同一事务内多次查询结果一致。可重复读（RR）——MySQL InnoDB 默认级别
事务启动时生成一致性视图（基于 MVCC），后续 SELECT 都读该快照。
✅ 解决脏读、不可重复读；✅ 通过间隙锁 + 临键锁大幅规避幻读（非标准 SQL 定义，是 InnoDB 的工程优化）。
注意：普通 SELECT 不会加锁，但 UPDATE/DELETE/SELECT ... FOR UPDATE 等会触发锁机制配合 MVCC。串行化（Serializable）
所有读操作隐式加共享锁，写操作加排他锁，等效于事务完全排队执行。
✅ 彻底解决脏读、不可重复读、幻读；❌ 并发能力归零，性能极差，仅用于极特殊强一致性校验场景。
二、底层怎么实现隔离？关键靠两类技术
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
MVCC（多版本并发控制）
主要支撑 RC 和 RR 级别下的“非阻塞读”。
每行记录隐含两个隐藏字段：trx_id（最后修改事务 ID）、rollptr（指向 undo log 中前一版本）。
事务开启时确定自己的read view，SELECT 时根据read view判断哪些版本可见，避免加锁读。锁机制（行锁、间隙锁、临键锁）
主要用于写操作（INSERT/UPDATE/DELETE）和显式加锁查询（如SELECT ... FOR UPDATE）。
RR 级别下，InnoDB 对 WHERE 条件涉及的索引区间加临键锁（Next-Key Lock），即“行锁 + 间隙锁”，从而阻止其他事务在该范围内插入新行，有效抑制幻读。
三、怎么选？看业务实际需求
- 对一致性要求不高、读多写少、能接受短暂不一致（比如用户中心首页展示）→ 可用 RC。
- 大多数 OLTP 场景（订单、支付、库存扣减）→ 推荐保持默认 RR，兼顾一致性与并发。
- 财务对账、审计类强一致性任务 → 可临时切为 Serializable，或改用
SELECT ... FOR UPDATE显式加锁。 - 绝对避免 RU，除非调试或测试极端场景。
注意：隔离级别设置影响的是当前会话或全局行为，可通过 SET SESSION TRANSACTION ISOLATION LEVEL xxx 动态调整，但需确保应用层逻辑与之匹配，否则可能引发意料外的并发异常。
