标签:数据 持久 日志 特征 最好 sel 版本 使用 lock
虽然平时已经很少使用MySQL了,但是数据库作为基本技能仍然不能忘,最近在学习数据库隔离级别,在此写下个人理解以备复习。
大家都知道数据库事务ACID(原子性、一致性、隔离性和持久性)的四个特征,也知道数据库存在三种并发问题(脏读、不可重复读、幻读),以及针对性的四种隔离级别(读未提交、读已提交、可重复读、序列化)。
解决与否 | 脏读 | 不可重复读 | 幻读 |
读未提交 | Yes | Yes | Yes |
读已提交 | No | Yes | Yes |
可重复读 | No | No | Yes |
串行化 | No | No | No |
特别提醒一句,隔离级别作用在连接(或会话)级别。客户端每次连接数据库的时候,都要根据自己对一致性的需求程度合理设置自己的事务隔离级别。
那么问题来了,MySQL底层是采用何种技术来实现这四种隔离级别的呢?
MySQL全表的数据存储在以主键为排序值的B+树索引中,叶子节点存储了相应主键的整行记录。需要指出的是,叶子节点的数据都是最新的数据,可能是事务提交后的一致状态,也可能是事务执行中的中间值(可能被回滚)。
当隔离级别设置为RU时:
当隔离级别是RC和RR时,就要谈到大名鼎鼎的MVCC(多版本控制) 技术。通过在每行加入若干隐藏的字段,它实现了不加锁的读操作,性能较好。
在事务开始的时候,除了正常往UNDO日志中写回滚的数据外,会创建一个ReadView,记录了当前活跃的其他事务的ID,其中最小值为Tmin,最大值为Tmax。
当执行SELECT操作时,MySQL顺着行记录的DATA_ROLL_PTR指针查找符合条件的历史版本。这里就用到了另一个隐藏列DATA_TRX_ID,其中存储的是更新该记录的事务ID(事务ID是全局递增且唯一的)。如果DELETE_BIT为1,则代表ID为DATA_TRX_ID的事务对当前行执行了删除。
扫描历史版本串成的链表的过滤条件是:
因为插入的数据版本号要么在活跃事务ID集合内、要么大于当前事务ID,所以MVCC机制同时解决了幻读问题。
需要指出的是,以上三个隔离级别中的读均为普通的SELECT。如果用的是SELECT ... LOCK IN SHARE MODE或SELCT ... FOR UPDATE,均属于当前读。即加写锁,读叶子节点最新值,如果更早的事务改了行值,依然会存在不可重复读的情况。
在RR级别下,如果WHERE的条件列上有唯一索引,那么MySQL只加行级锁;如果是普通索引,会加间隙锁来防止幻读;如果没有索引,就会采用表锁,大大降低并发写的能力。
读写均加表级的读写锁即可,直接读主键索引B+树的叶子节点的最新数据。该级别下,数据一致性很强,但是并发写的能力非常差。
标签:数据 持久 日志 特征 最好 sel 版本 使用 lock
原文地址:https://www.cnblogs.com/shishaochen/p/9384321.html