小型门户网站模板,seo网站代码,专业网站定制价格便宜,前端开发做网站吗一、数据库事务隔离级别
数据库事务的隔离级别有4种#xff0c;由低到高分别为Read uncommitted #xff08;读未提交#xff09;、Read committed#xff08;读提交#xff09; 、Repeatable read#xff08;可重复读#xff09; 、Serializable #xff08;串行化由低到高分别为Read uncommitted 读未提交、Read committed读提交 、Repeatable read可重复读 、Serializable 串行化。
1、脏读、不可重复读、幻读
在数据库多个事务并发执行的情况下不同的隔离级别可能会出现脏读、不可重复读、幻读这几种问题。
脏读读取到未提交的数据。事务A对某条数据进行了修改但还未提交这时事务B读取到了这条未提交的数据。如果事务A出错回滚事务B读取到的数据就是一条脏数据。 不可重复读 同一事务内多次查询某条数据的结果不一致。事务A对某条数据执行了两次查询在这两次查询的时间间隔内事务B对该条数据执行了修改update导致事务A的两次查询结果不一致。 幻读 同一事务内多次查询的结果集不一致多或少了几条数据。事务A以相同的查询条件执行了两次查询在这两次查询的时间间隔内事务B新增或删除insert|delete了几条数据导致事务A的两次查询结果集不一致。
2、四种隔离级别
读未提交 Read uncommitted 最低隔离级别允许事务读取其他事务未提交的更改。可能导致脏读、不可重复读、幻读问题。
读提交Read Committed 事务只能读取到已提交的数据。可以解决脏读问题但是还会有可能不可重复读、幻读问题。
可重复读(Repeated Read) 专门针对“不可重复读”这种情况而制定的隔离级别。可以解决脏读和不可重复读问题但还是有可能出现幻读问题。MYSQL默认的隔离级别
串行化Serializable 最高隔离级别所有事务都串行化顺序执行不存在并发从而完全防止脏读、不可重复读和幻读问题。但是这种隔离级别性能较低基本不会使用。
二、多版本并发控制MVCC
1、什么是多版本并发控制MVCC
多版本并发控制英文全称是 Multiversion Concurrency Control简称 MVCC。
MVCC是通过保存数据行的历史版本组成版本链对比事务ID与版本号来确定当前事务应该使用哪个历史版本数据而无需加锁就可以保证事务的隔离效果可以认为是一种不加锁的行锁可以提高数据库的性能。
MySQL的大多数事务型存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑它们一般都同时实现了多版本并发控制MVCC。不仅是MySQL包括Oracle、PostgreSQL等其他数据库系统也都实现了MVCC但各自的实现机制不尽相同因为MVCC没有一个统一的实现标准典型的有乐观optimistic并发控制和悲观pessimistic并发控制。
2、MVCC可以解决哪些问题
1读写之间阻塞的问题 MVCC可以让读写操作互不阻塞即读不阻塞写写不阻塞读。相较于普通锁串行运行、读写锁可以实现读读并发MVCC提升数据库事务并发处理能力。 2降低了死锁的概率 MVCC大多数情况不用加锁写数据时也只是加行锁降低了死锁的概率 3 解决一致性读的问题 一致性读也叫快照读当查询数据库在某个时间点的快照时只能看到这个时间点之前事务提交更新的结果或者本事务提交的结果而不能看到这个时间点之后事务提交的更新的结果。
3、快照读与当前读
在MySQL InnoDB中MVCC主要是为了提高数据库并发性能以更好的方式处理读-写冲突不用加锁实现并发读-写。这个读就是快照读而非当前读当前读实际上是一种加锁的操作是悲观锁的实现。而MVCC本质是采用乐观锁思想的一种方式。 1快照读 快照读又叫一致性读读取的是快照数据。是一种一致性不加锁的读。不加锁的简单的 SELECT 都属于快照读。例如
SELECT * FROM t WHERE id1快照读可能读到的并不一定是数据的最新版本而有可能是之前的历史版本。快照读的前提是隔离级别不是串行级别串行级别下的快照读会退化成当前读。 2当前读 当前读读取的是记录的最新版本最新数据而不是历史版本的数据读取时还要保证其他并发事务不能修改当前记录会对读取的记录进行加锁。加锁的 SELECT或者对数据进行增删改都会进行当前读。
SELECT * FROM t LOCK IN SHARE MODE; # 共享锁SELECT * FROM t FOR UPDATE; # 排他锁INSERT INTO t values ... # 排他锁DELETE FROM t WHERE ... # 排他锁UPDATE t SET ... # 排他锁4、InnoDB的MVCC原理
1隐藏字段和Undo Log版本链
隐藏字段 对于使用 InnoDB 存储引擎的表来说它的聚簇索引的叶子节点为数据页存放的就是整张表的数据行而每个数据行中有一些重要的隐藏字段。
DB_ROW_ID大小为6字节默认主键列如果表没有设置主键InnoDB会自动生成该隐藏主键列。DB_TRX_ID大小为6字节生成该行数据历史版本的事务ID。DB_ROLL_PTR大小为7字节回滚指针指向上一个版本的Undo logInnoDB 便是通过这个指针找到之前版本的数据该行数据的所有版本记录都在undo中通过链表形式组织在一起。
另外每条记录的头信息record header里都有一个专门的 bitdeleted_flag来表示当前记录是否已经被删除 Undo log版本链 每次对数据行进行改动都会生成一条undo日志每条undo日志也都有一个 DB_ROLL_PTR属性INSERT 操作对应的undo日志没有该属性因为该记录并没有更早的版本。版本链示例如下
2ReadView
在多事务并发修改同一行数据的情况下MVCC通过隐藏字段和Undo Log生成了该行记录的历史版本快照并组成了版本链。但是事务读取数据时该读取哪个版本的数据需要一个读取机制来确定。这时就用到了ReadView可读视图。 设计思路 1使用 READ UNCOMMITTED 隔离级别的事务由于可以读到未提交事务修改过的记录所以直接读取记录的最新版本就好 2使用 SERIALIZABLE 隔离级别的事务InnoDB规定使用加锁的方式来访问记录 3使用 READ COMMITTED 和 REPEATABLE READ 隔离级别的事务都必须保证读到已经提交了的 事务修改过的记录。假如另一个事务已经修改了记录但是尚未提交是不能直接读取最新版本的记录的核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的这是ReadView要解决的主要问题
ReadView内容 ReadView主要包含以下4个内容 1creator_trx_id 创建当前ReadView的事务ID。注意只有在对表中的记录做改动时执行INSERT、DELETE、UPDATE这些语句时才会为事务分配事务ID否则在一个只读事务中的事务ID值都默认为0。 2trx_ids 生成ReadView时当前系统活跃的事务ID集合活跃的事务表示还未提交的事务。 3up_limit_id 活跃的事务中最小的事务ID 4low_limit_id 表示生成ReadView时系统中应该分配给下一个事务的 id 值即最大事务ID1。
ReadView的规则 1如果某行数据被访问版本的trx_id属性值与ReadView中的 creator_trx_id 值相同意味着当前事务在访问它自己修改过的记录所以该版本可以被当前事务访问。
2如果某行数据被访问版本的trx_id属性值小于ReadView中的 up_limit_id值表明生成该版本的事务在当前事务生成ReadView前已经提交所以该版本可以被当前事务访问。
3如果某行数据被访问版本的trx_id属性值大于或等于ReadView中的 low_limit_id 值表明生成该版本的事务在当前事务生成ReadView后才开启所以该版本不可以被当前事务访问。
4如果某行数据被访问版本的trx_id属性值在ReadView的 up_limit_id 和 low_limit_id 之间那就需要判断一下trx_id属性值是不是在 trx_ids 列表中。 a. 如果在说明创建ReadView时生成该版本的事务还是活跃的该版本不可以被访问 b. 如果不在说明创建ReadView时生成该版本的事务已经被提交该版本可以被访问
3MVCC快照读的整体流程
当查询一条记录的时候系统通过如下流程MVCC找到合适的记录
1首先获取事务自己的版本号也就是事务 ID
2获取 ReadView
3查询得到的数据然后与 ReadView 中的事务版本号进行比较
4如果不符合 ReadView 规则就需要从 Undo Log 中获取历史快照
5最后返回符合规则的数据
如果某个版本的数据对当前事务不可见的话那就顺着版本链找到下一个版本的数据继续按照上边的步骤判断可见性。以此类推直到版本链中的最后一个版本。如果最后一个版本也不可见的话那么就意味着该条记录对该事务完全不可见查询结果就不包含该记录。
4MVCC解决不可重复读和幻读原理
当隔离级别为读提交Read Committed时一个事务中的每一次 SELECT 查询都会重新获取一次ReadView。当隔离级别为可重复读(Repeated Read)时一个事务只在第一次 SELECT 的时候会获取一次ReadView而后面所有的SELECT都会复用这个ReadView。
1READ COMMITTED隔离级别
假设事务A、B的事务ID分别为10、20并且事务正在执行还未提交
# Transaction A ID10
BEGIN;
UPDATE t SET name李四 WHERE id1;
UPDATE t SET name王五 WHERE id1;
# Transaction B iD20
BEGIN;
UPDATE t SET name赵六 WHERE id1;此时id为1的数据的版本链如下 此时另一个事务C开始执行
# 使用READ COMMITTED隔离级别的事务C ID21
BEGIN;
# 事务A和B都未提交
# SELECT1
SELECT * FROM t WHERE id 1; # 得到的列name的值为张三SELECT1生成的ReadView的trx_ids[10,20,21]up_limit_id10low_limit_id22creator_trx_id为0。从“赵六”那个版本开始查找因为10、20都在trx_ids里所以符合的版本只有trx_id5的版本数据。
此时把事务A提交
# Transaction A ID10
BEGIN;
UPDATE student SET name李四 WHERE id1;
UPDATE student SET name王五 WHERE id1;
COMMIT;然后在事务C中继续查询
# 使用READ COMMITTED隔离级别的事务C ID21
BEGIN;
# 事务A和B都未提交
# SELECT1
SELECT * FROM t WHERE id 1; # 得到的列name的值为张三
#SELECT2
SELECT * FROM t WHERE id 1; # 得到的列name的值为王五SELECT2会生成新的ReadView新ReadView的trx_ids[20,21]up_limit_id20low_limit_id22creator_trx_id为0。还是从“赵六”那个版本开始查找此时只有20在trx_ids里。所以trx_id10的版本对SELECT2是可见的SELECT2查找到的结果就是“王五”那个版本数据。
2REPEATABLE READ隔离级别
操作同上。但是在SELECT2时REPEATABLE READ隔离级别是不会重新生成ReadView的所以SELECT2使用的还是SELECT1的ReadView。所以查出来的结果和SELECT1是一致的都是trx_id5的版本数据。这样就解决了不可重复读的问题。
5MVCC解决幻读原理
假设表t中有一条id为1的数据trx_id10
现在有事务AID20、事务BID30并行执行
# Transaction A ID20
BEGIN;
#SELECT1
SELECT * FROM t WHERE id 1; SELECT创建的ReadView的内容为trx_ids[20,30] up_limit_id20 low_limit_id31 creator_trx_id0。根据ReadView的规则id1的数据的trx_id10up_limit_id,所以事务A能查出来。
此时事务B插入两条数据并提交
# Transaction B ID30
BEGIN;
insert into t(id,name) values(2,李四);
insert into t(id,name) values(3,王五);
COMMIT;然后事务A再次查询
# Transaction A ID20
BEGIN;
#SELECT1
SELECT * FROM t WHERE id 1;
#SELECT2
SELECT * FROM t WHERE id 1; 因为是REPEATABLE READ隔离级别SELECT2不创建新的ReadView使用SELECT1的ReadView。ReadView的内容为trx_ids[20,30] up_limit_id20 low_limit_id31 creator_trx_id0。因为id为2,3的两条数据的trx_id30,在trx_ids里所以事务A不能查出来。 所以MYSQL的InnoDB在REPEATABLE READ隔离级别下不会出现幻读的情况。
