【DBMS】如何理解影响事务ACID特性的三大问题
我们都知道要保证数据库数据的完整性，在允许事务并发运行时必须保证其ACID特性。而不可重读、丢失修改 和 读脏数据 三大问题破坏了事务的ACID特性。
在不可重读问题中，假设事务T1开始后1s读入数据B，在T1开始后4s再次读入数据B。但是在T1开始后第二秒事务T2正巧修改了数据B。此时则发生了不可重读问题。我们拿做饭打个比方。厨师T1在1:01分查看了一下菜篮B中还有一根香蕉，于是准备做有香蕉的水果沙拉。1:02分，趁T1不注意，厨师T2取走了香蕉B换成了苹果。1:04分准备好沙拉酱和其他原料的T1回来取B中的香蕉，发现香蕉没了被偷换成了苹果，于是香蕉水果沙拉的计划泡汤。不可重读问题直接破坏了T1的一致性。
在丢失修改问题中，T1读到数据A，接着T2也来读到了数据A。然后T1加以操作并写回A1，最后T2加以操作并写回A2。举例来说，学生T1与学生T2先后向老师提出了负责教室黑板报A的事宜。老师（DBMS）未做到通知对方。T1先出完了板报。T1走后T2以为T1刚刚制作完成的板报是过期的于是擦掉了T1的作品，画上了T2自己的作品。然后T1，T2又来向老师请功。老师把奖励颁给T1委屈了T2，把奖励颁发给T2又委屈了T1。
在读脏数据问题中，事务T1持续时间为5s。T1开始后1s首先读到了数据C加以操作并在第二秒写回C1。所以T1开始后3秒T2读到了C1。T1进行到第四秒发生事务内部故障，做了回滚操作C1被改写为原先的C。那么便说T2读到了无效的脏数据C1。如果C1有效则破坏了T1的持续性，如果C1是脏数据，则破坏了T2的隔离性。例如公司T1将工程C外包给公司T2。T2未完成工程C之前T1宣布破产并撤走了所有资金，T2吃了亏，拿到了脏工程C。
于是DBMS为了解决以上三大问题引入了对资源／数据加锁的方法。使用两段锁协议或三级封锁协议进一步明确了加锁的条件，从而保证了事务在并发运行时的ACID特性。由此带来的死锁与活锁问题本帖不予讨论。
页:
[1]