为什么保证隔离性可以防止多个事务并发度写同一个数据的时候,导致数据不一致?

文章目录1. 核心武器排他锁Exclusive Locks / X锁2. 防止“丢失更新”Lost Update3. 隔离级别对“写”的统一底线4. 隔离性与原子性A的联动总结面试加分表达 深度思考要理解为什么“隔离性”能防止数据不一致我们需要把隔离性的目标和实现它的手段锁联系起来。简单来说隔离性Isolation的核心逻辑是虽然事务是并发运行的但数据库要让它们看起来像是排队一个接一个执行的。对于“写-写”并发隔离性主要通过以下三个层面的机制来确保一致性1. 核心武器排他锁Exclusive Locks / X锁当你保证了隔离性就意味着数据库在底层执行了一套“准入制度”。逻辑只要一个事务事务 A尝试修改UPDATE/DELETE某行数据它必须先获得这行数据的X 锁。排他性X 锁是“独占”的。在事务 A 提交或回滚释放锁之前任何其他事务事务 B如果也想写这行数据就会被阻塞进入Lock Wait状态。2. 防止“丢失更新”Lost Update如果没有隔离性保护多个事务同时写同一个数据会发生最可怕的灾难丢失更新。错误场景没有隔离性账户余额 100 元。事务 A 读取 100准备加 50逻辑计算中。事务 B 读取 100准备扣 30逻辑计算中。事务 A 写回 150。事务 B 写回 70。结果事务 A 的加钱操作完全消失了这就叫“数据不一致”。正确场景有隔离性/加锁事务 A 准备写先给这行加上X 锁。事务 B 也想写发现有锁只能在旁边等着。事务 A 把 100 改成 150提交释放锁。事务 B 拿到锁此时它读取到的是最新的150再减去 30写回120。结果逻辑正确两次修改都生效了。3. 隔离级别对“写”的统一底线虽然 MySQL 有四种隔离级别RU, RC, RR, Serializable它们对“读”的限制各不相同但对于**“写”**它们有一条共同的底线所有隔离级别在修改数据时都必须获取行级排他锁。这意味着隔离性在底层强制实现了**“并发写”在微观上的“串行化”**。即使你把隔离级别调到最低的Read Uncommitted两个事务也没法在同一毫秒内同时成功修改同一行数据而不排队。4. 隔离性与原子性A的联动隔离性不仅仅是锁它还保证了中间状态不可见。如果事务 A 改了一半数据还没提交。如果没有隔离性事务 B 可能会基于这个“中间状态”去写。万一事务 A 随后回滚了事务 B 写的数据就基于一个不存在的幻影导致逻辑崩盘脏写。隔离性通过加锁确保了只有当一个事务完整地写完并确定Commit后下一个事务才能基于这个确定的结果继续写。总结面试加分表达当面试官问到这一点时你可以这样总结“隔离性通过锁机制Locking将并发的写操作在物理层面转变为串行执行。它确保了每一个写操作都是基于前一个事务提交后的最终状态进行的从而消除了‘丢失更新’和‘脏写’的风险。换句话说隔离性是通过暂时牺牲‘写’的并发速度来换取数据的绝对一致性。” 深度思考既然“写”一定要排队那如果两个事务互相等待对方的锁就会发生死锁Deadlock。