事务隔离级别直接决定了并发读写时一个事务能看到什么、看不到什么，它是平衡数据一致性与数据库性能的核心旋钮。想象一下，多个请求同时操作同一行数据，如果没人管，就会读到中间状态、前后不一致甚至凭空多出来的数据，这篇文章就把四种隔离级别掰开揉碎，讲清楚它们如何影响数据可见性，以及你在实战中该怎么选。
并发读写中的“脏数据”从哪来：可见性问题的本质
数据库处理并发事务时,最怕的就是多个事务同时读写同一条数据，数据可见性之所以出问题，本质上是因为事务之间没有完全隔离，一个事务的中间状态被另一个事务“偷看”到了，业内专家指出，大多数并发异常都不是数据库本身出错，而是隔离级别定得太低，让不该见的中间状态漏了出去。
举个贴近生活的例子,你在银行App转账，账户余额从1000元变成900元的这个过程中，如果另一个查询事务恰好在这瞬间读取，看到的是1000元还是900元？如果看到的是扣款前的老数据，那后果可能很严重，这个毫秒级的窗口期，就是事务隔离级别要治理的核心区域。
“脏读”是如何发生的：低隔离级别下的数据泄露风险
脏读是所有并发问题里最直观的一种,它的定义是：一个事务读到了另一个事务尚未提交的数据，如果那个事务回滚了，你读到的东西就凭空消失了，像做了一场梦。
假设小张把商品价格从100元改成120元,但还没点提交，此时小李的查询事务恰好在同一时刻读取，用的是较低的隔离级别，他看到的就可能是120元这个“临时价格”，小张随后反悔，把价格改回了100元并提交，小李刚才读到120元就成了幽灵数据，低隔离级别就像一扇没上锁的门，任何中间状态都可能被路人看见。
在读未提交（READ UNCOMMITTED）级别下，脏读完全不被阻止，事务可以随意读取其他事务未提交的修改，这种级别的唯一优势是性能极好，几乎不加锁，但绝大多数业务场景都拒绝使用，因为数据可信度太低。读已提交（READ COMMITTED）级别则修掉了这个漏洞，事务只能读取到已提交的数据，中间状态被屏蔽在外，这是很多主流数据库的默认级别，比如Oracle和PostgreSQL，它用行级锁加快照机制，在性能和一致性之间取了平庸但稳健的平衡点。
不可重复读：同一事务内两次查询结果为何“变脸”
如果说脏读是“读别人没提交的”，那不可重复读就是“读自己已经提交了的环境里的另外一码事”，它的定义是：同一事务内，两次相同的查询返回了不同的结果，因为期间有其他事务提交了修改。
继续用余额举例,你开启一个事务做报表，第一次查询账户A的余额是5000元，同一事务内，第二次查询同一个账户，余额变成了4500元，中间隔了不过几秒钟，另一笔转账事务提交了，修改了这行数据，你的报表无法解释这个差异，因为同一事务内的数据快照前后不一致。
读已提交
级别无法阻止这种场景，因为它每次查询都重新生成快照，天然就会“看见”新提交的数据，想要在事务开始时就固定住数据的“合影”，让整个事务期间看到的是同一个快照，就需要更高级别的隔离。
幻读：查询条件没变，结果集却多出了“新面孔”
幻读与不可重复读容易混淆,但它们的本质不同，不可重复读针对的是同一行数据被修改，而幻读针对的是符合查询条件的结果集合发生了变化有新行插入，或者有行被删除，使得第二次查询多出或缺少了记录。
比如你执行查询“SELECT FROM orders WHERE amount > 100”，第一次返回10条记录，同一事务内再执行一次同样的查询，返回了11条，多出来的那条记录是另一个事务在期间提交的新订单，你像见了鬼一样，因为行数变了，读已提交和可重复读（REPEATABLE READ）级别下，幻读都可能出现，可重复读通过快照机制锁住了已存在行的可见性，但它不对“未来将被插入的数据范围”加锁，因此幻读依旧存在，只有可串行化（SERIALIZABLE）级别，通过范围锁或谓词锁，把整个查询范围锁死，才能彻底阻止新记录“闯入”查询视野。
谈谈MySQL中事务隔离级别 脏读 不可重复读 幻读的实际表现
行业公认的四种隔离级别,在MySQL InnoDB引擎下的表现与传统SQL标准略有差异，很多开发者问起MySQL中事务隔离级别 脏读 不可重复读 幻读分别是什么表现，这里就该说清楚了。默认的REPEATABLE READ（可重复读）在InnoDB中借助间隙锁，已经能大概率规避幻读，这是InnoDB与标准SQL行为最不一样的地方，它比标准定义得更严格，因此在默认级别下，多数业务不会遇到幻读困扰。
这里列一个常见隔离级别与可见性表现对比表格：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 典型默认数据库 |
|---|---|---|---|---|
| 读未提交 | 可能发生 | 可能发生 | 可能发生 | 极少用 |
| 读已提交 | 不会发生 | 可能发生 | 可能发生 | Oracle, PostgreSQL |
| 可重复读 | 不会发生 | 不会发生 | InnoDB中基本避免 | MySQL InnoDB |
| 可串行化 | 不会发生 | 不会发生 | 不会发生 | 极少用，性能代价高 |
可重复读如何“固定”可见性快照
在MySQL中,可重复读级别下，事务第一次执行SELECT时，会生成一个一致性快照（视图），此后直到事务结束，所有普通查询都基于这个快照读取，因此不会看到其他事务新提交的修改，这就解释了为什么同一个事务内，两次查询结果能保持一致。快照读是不加锁的，性能好，但如果你打算对数据执行UPDATE或SELECT ... FOR UPDATE这类当前读，那就会走最新数据加锁，快照机制不生效，这是很多开发者在高并发场景下踩坑的地方，要特备注意。
可串行化：以锁表换一致性的极端方案
可串行化级别是隔离的终极形态，它强制事务按顺序执行，相当于给读写都加上范围锁，用这种级别，并发性能会断崖式下降，因为事务之间的锁冲突极其频繁，很多场景下几乎等同于串行排队，它的价值在于数据绝对一致，所有异常现象都会消失，多用于对一致性要求极高、并发量极小的场景，比如财务对账、核心结算模块，绝大多数互联网业务不会使用这个级别，因为并发吞吐撑不住。
从实际场景出发，数据库隔离级别如何选择更稳妥
了解数据库隔离级别如何选择,需要一个朴素的判断方法：先想清楚业务能容忍哪类数据异常，如果业务读多写少且数据一致性要求高，比如订单系统、账户系统，优先选择可重复读或读已提交，如果业务对实时性要求高，比如日志、行为记录类，读已提交就够用，没必要承受可重复读带来的额外锁开销。
高并发库存扣减场景
以电商库存为例,多个请求同时扣减同一件商品的库存，这是经典的并发写冲突场景，如果隔离级别设得低，可能出现超卖（读到未提交的中间库存，导致两个事务都认为库存充足），行业内通常的做法是：使用读已提交级别，配合UPDATE inventory SET stock = stock - 1 WHERE id = ? AND stock > 0这样的原子更新语句，利用行锁保证扣减操作互斥，此时不需要可串行化那样的大范围锁，因为原子更新已经保护了数据可见性的关键环节，这是较低隔离级别配合乐观锁或条件更新解决并发覆盖的典型例子。
报表统计与长事务场景
财务报表通常需要在一个事务里执行多条统计查询,要求全过程中数据保持一致，如果使用读已提交，两条查询落在不同时间点，新提交的数据会让结果对不上，此时选择可重复读，事务开始后的整个视野都固定，报表数据才可信，但要注意，长事务持有的快照会占用undo log资源，如果事务执行时间过长，可能会导致数据库清理不及时，膨胀存储空间，行业内共识是尽量缩短事务时间，把大查询拆解成批量操作，减少快照生存期。
聊聊数据库并发控制的常见问题
可重复读 防幻读 用的是什么锁机制
可重复读级别下,InnoDB通过快照读（MVCC）保证普通SELECT的可见性一致，又通过当前读加锁配合间隙锁（Gap Lock）与临键锁（Next-Key Lock）阻止幻读，具体到操作，当执行SELECT FROM orders WHERE amount > 100 FOR UPDATE这样的语句时，InnoDB会对范围内所有已存在的行加行锁，同时对范围前后的间隙加间隙锁，阻止其他事务插入落入范围内的新记录，这套锁组合是MySQL在可重复读级别下能超过标准定义、有效抵御幻读的根本原因。
事务隔离级别对数据库性能影响有多大
隔离级别越高,锁范围越大，阻塞概率越高，性能的下降越明显。
可串行化级别的性能和可重复读级别之间，差距往往是一个量级，在多数读写混合场景下难以承受，读已提交级别和可重复读级别之间的性能差异，在多数业务中并不大，因为InnoDB的快照读本身不加锁，主要差别来自间隙锁引入的插入阻塞，如果业务允许，且MySQL版本支持，可以手动调整隔离级别来规避间隙锁带来的不必要等待，用SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;可以临时降级，但要自己承担不可重复读发生的代价。
如何在MySQL中查看和修改隔离级别
用MySQL客户端连接后,执行SELECT @@transaction_isolation;可以查当前会话的隔离级别，通常返回REPEATABLE-READ，临时修改当前会话的执行语句是SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;，动态修改全局默认值，需要执行SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;，但要注意该操作对已存在的连接不生效，且需要在配置文件或者重启服务后保留设置，修改前务必确认业务对数据可见性的要求的确能接受，否则容易埋下隐患。
事务隔离级别不只是一个数据库参数,它直接塑造了并发场景下数据可见性的边界，决定了哪些读写异常会被允许发生，从读未提交到可串行化，每一级提升都在用锁和快照机制换取更严谨的数据视图，但同时也牺牲了部分并发空间，实战中最关键的动作是评估业务对脏读、不可重复读、幻读的容忍度，再结合行锁、间隙锁、MVCC这些底层机制，选定一个合适的默认级别，没有放之四海皆准的答案，只有匹配业务场景的合适配置。
事务隔离级别与并发读写常见问题解答
问：MySQL默认的事务隔离级别是什么，为什么会引发死锁？
MySQL InnoDB引擎默认隔离级别是REPEATABLE READ（可重复读），因为它为了解决幻读引入了间隙锁，这个锁机制在高并发插入场景下会扩大锁范围，事务之间等待彼此释放锁资源的概率也随之上升，从而更容易出现死锁，多数死锁可以通过调整SQL执行顺序或改小事务范围来避免。
问：事务隔离级别设置得太低，最直接的后果是什么？
最直接后果是数据可见性失控,当前事务可能读到其他事务未提交的修改，如果那个事务最终回滚，就会产生脏读，导致业务做出错误的判断，比如统计报表多算了一笔不存在的订单，库存扣减把未提交的扣减当作已经完成的提交来累加，这些错误数据一旦流入下游系统，排查会非常困难。
问：同一个事务内两次查询结果不一致，是隔离级别的问题还是代码逻辑的问题？
多数情况下是隔离级别设置过低导致的,如果隔离级别是读已提交，同一事务内两次查询之间恰好有其他事务提交了修改，结果就会不一致，若想固定事务内的数据快照，应该使用可重复读级别，它会在事务开始时建立一致性视图，之后的查询都基于该视图，从而保证前后一致。