企业网站微信公众号的建设事迹,林州建筑网,建设通官方网站,wordpress 文章 分类 页面一、数据库事务隔离级别 数据库事务的隔离级别有4个#xff0c;由低到高依次为Read uncommitted 、Read committed 、Repeatable read 、Serializable #xff0c;这四个级别可以逐个解决脏读 、不可重复读 、幻读 这几类问题。 √: 可能出现 : 不会出现 脏读不可重复读幻…一、数据库事务隔离级别 数据库事务的隔离级别有4个由低到高依次为Read uncommitted 、Read committed 、Repeatable read 、Serializable 这四个级别可以逐个解决脏读 、不可重复读 、幻读 这几类问题。 √: 可能出现 ×: 不会出现 脏读不可重复读幻读Read uncommitted√√√Read committed×√√Repeatable read××√Serializable××× 注意我们讨论隔离级别的场景主要是在多个事务并发 的情况下因此接下来的讲解都围绕事务并发。
Read uncommitted 读未提交
公司发工资了领导把5000元打到singo的账号上但是该事务并未提交而singo正好去查看账户发现工资已经到账是5000元整非常高 兴。可是不幸的是领导发现发给singo的工资金额不对是2000元于是迅速回滚了事务修改金额后将事务提交最后singo实际的工资只有 2000元singo空欢喜一场。 出现上述情况即我们所说的脏读 两个并发的事务“事务A领导给singo发工资”、“事务Bsingo查询工资账户”事务B读取了事务A尚未提交的数据。
当隔离级别设置为Read uncommitted 时就可能出现脏读如何避免脏读请看下一个隔离级别。
Read committed 读提交
singo拿着工资卡去消费系统读取到卡里确实有2000元而此时她的老婆也正好在网上转账把singo工资卡的2000元转到另一账户并在 singo之前提交了事务当singo扣款时系统检查到singo的工资卡已经没有钱扣款失败singo十分纳闷明明卡里有钱为 何......
出现上述情况即我们所说的不可重复读 两个并发的事务“事务Asingo消费”、“事务Bsingo的老婆网上转账”事务A事先读取了数据事务B紧接了更新了数据并提交了事务而事务A再次读取该数据时数据已经发生了改变。
当隔离级别设置为Read committed 时避免了脏读但是可能会造成不可重复读。
大多数数据库的默认级别就是Read committed比如Sql Server , Oracle。如何解决不可重复读这一问题请看下一个隔离级别。
Repeatable read 重复读
当隔离级别设置为Repeatable read 时可以避免不可重复读。当singo拿着工资卡去消费时一旦系统开始读取工资卡信息即事务开始singo的老婆就不可能对该记录进行修改也就是singo的老婆不能在此时转账。
虽然Repeatable read避免了不可重复读但还有可能出现幻读 。
singo的老婆工作在银行部门她时常通过银行内部系统查看singo的信用卡消费记录。有一天她正在查询到singo当月信用卡的总消费金额 select sum(amount) from transaction where month 本月为80元而singo此时正好在外面胡吃海塞后在收银台买单消费1000元即新增了一条1000元的消费记录insert transaction ... 并提交了事务随后singo的老婆将singo当月信用卡消费的明细打印到A4纸上却发现消费总额为1080元singo的老婆很诧异以为出 现了幻觉幻读就这样产生了。
注MySQL的默认隔离级别就是Repeatable read。
Serializable 序列化
Serializable 是最高的事务隔离级别同时代价也花费最高性能很低一般很少使用在该级别下事务顺序执行不仅可以避免脏读、不可重复读还避免了幻像读。 二、脏读、幻读、不可重复读
1.脏读 脏读就是指当一个事务正在访问数据并且对数据进行了修改而这种修改还没有提交到数据库中这时另外一个事务也访问这个数据然后使用了这个数据。
2.不可重复读 是指在一个事务内多次读同一数据。在这个事务还没有结束时另外一个事务也访问该同一数据。那么在第一个事务中的两次读数据之间由于第二个事务的修改那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的因此称为是不可重复读。即不能读到相同的数据内容 例如一个编辑人员两次读取同一文档但在两次读取之间作者重写了该文档。当编辑人员第二次读取文档时文档已更改。原始读取不可重复。如果只有在作者全部完成编写后编辑人员才可以读取文档则可以避免该问题。
3.幻读: 是指当事务不是独立执行时发生的一种现象例如第一个事务对一个表中的数据进行了修改这种修改涉及到表中的全部数据行。同时第二个事务也修改这个表中的数据这种修改是向表中插入一行新数据。那么以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行就好象 发生了幻觉一样。 例如一个编辑人员更改作者提交的文档但当生产部门将其更改内容合并到该文档的主复本时发现作者已将未编辑的新材料添加到该文档中。如果在编辑人员和生产部门完成对原始文档的处理之前任何人都不能将新材料添加到文档中则可以避免该问题。 二、传播行为 1、PROPAGATION_REQUIRED如果当前没有事务就创建一个新事务如果当前存在事务就加入该事务该设置是最常用的设置。
2、PROPAGATION_SUPPORTS支持当前事务如果当前存在事务就加入该事务如果当前不存在事务就以非事务执行。
3、PROPAGATION_MANDATORY支持当前事务如果当前存在事务就加入该事务如果当前不存在事务就抛出异常。
4、PROPAGATION_REQUIRES_NEW创建新事务无论当前存不存在事务都创建新事务。
5、PROPAGATION_NOT_SUPPORTED以非事务方式执行操作如果当前存在事务就把当前事务挂起。
6、PROPAGATION_NEVER以非事务方式执行如果当前存在事务则抛出异常。
7、PROPAGATION_NESTED如果当前存在事务则在嵌套事务内执行。如果当前没有事务则执行与PROPAGATION_REQUIRED类似的操作。 MVCC是如何解决幻读方式 MySQL的大多数事务型存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑它们一般都同时实现了多版本并发控制MVCC。不仅是MySQL包括Oracle、PostgreSQL等其他数据库系统也都实现了MVCC但各自的实现机制不尽相同因为MVCC没有一个统一的实现标准。 可以认为MVCC是行级锁的一个变种但是它在很多情况下避免了加锁操作因此开销更低。虽然实现机制有所不同但大都实现了非阻塞的读操作写操作也只锁定必要的行。 MVCC的实现是通过保存数据在某个时间点的快照来实现的。也就是说不管需要执行多长时间每个事务看到的数据都是一致的。根据事务开始的时间不同每个事务对同一张表同一时刻看到的数据可能是不一样的。如果之前没有这方面的概念这句话听起来就有点迷惑。熟悉了以后会发现这句话其实还是很容易理解的。 前面说到不同存储引擎的MVCC实现是不同的典型的有乐观optimistic并发控制控制和悲观pessimistic并发控制。
下面我们通过InnoDB的简化版行为来说明MVCC是如何工作的。 InnoDB的MVCC是通过在每行记录后面保存两个隐藏的列来实现的。这两个列一个保存了行的创建时间一个保存行的过期时间或删除时间。当然存储的并不是实际的时间值而是系统版本号systemversionnumber。每开始一个新的事务系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号用来和查询到的每行记录的版本号进行比较。下面看一下在REPEATABLEREAD隔离级别下MVCC具体是如何操作的。
SELECT InnoDB会根据以下两个条件检查每行记录InnoDB只查找版本早于当前事务版本的数据行也就是行的系统版本号小于或等于事务的系统版本号这样可以确保事务读取的行要么是在事务开始前已经存在的要么是事务自身插入或者修改过的。行的删除版本要么未定义要么大于当前事务版本号。这可以确保事务读取到的行在事务开始之前未被删除。只有符合上述两个条件的记录才能返回作为查询结果。
INSERT InnoDB为新插入的每一行保存当前系统版本号作为行版本号。
DELETE InnoDB为删除的每一行保存当前系统版本号作为行删除标识。
UPDATE InnoDB为插入一行新记录保存当前系统版本号作为行版本号同时保存当前系统版本号到原来的行作为行删除标识。保存这两个额外系统版本号使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单性能很好并且也能保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间需要做更多的行检查工作以及一些额外的维护工作。MVCC只在REPEATABLEREAD和READCOMMITTED两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容(4)因为READUNCOMMITTED总是读取最新的数据行而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。
