西安网站推广公司电话,数据中心公司排名,如何注册营业执照,门户网站要求目录
一、事务的四大特性#xff08;ACID#xff09;
1. 原子性(atomicity)#xff1a;
2. 一致性(consistency)#xff1a;
3. 隔离性(isolation)#xff1a;
4. 持久性(durability)#xff1a;
二、死锁的产生及解决方法
三、事务的四种隔离级别
0 .封锁协议
…目录
一、事务的四大特性ACID
1. 原子性(atomicity)
2. 一致性(consistency)
3. 隔离性(isolation)
4. 持久性(durability)
二、死锁的产生及解决方法
三、事务的四种隔离级别
0 .封锁协议
1 读未提交(Read uncommitted)
2. 读已提交(Read committed)
3. 可重复读(Repeatable read)
4. 串行化(Serializable) 四、MVCCMulti-Version Concurrency Control
1 为什么会有MVCC
2 MVCC在哪个隔离级别下才生效
3 ReadView是什么 五、不同隔离级别演示
演示准备
读未提交-----脏读
读已提交-----不可重复读
可重复读-----幻读
串行化 一、事务的四大特性ACID
1. 原子性(atomicity) 事务是一个原子操作要么全部执行成功要么全部执行失败。 事务的原子性确保一组逻辑操作要么全部完成要么完全不起作用。 2. 一致性(consistency) 事务失败当前事务都会回滚事务成功其他事务可见 3. 隔离性(isolation) 事务的隔离性是指在并发执行的多个事务中每个事务相互独立互不影响 事务隔离级别越高数据冲突的可能性就越小但并发性能也会受到一定的影响。 4. 持久性(durability) 一个事务被提交之后。它对数据库中数据的改变是持久的即使数据库发生故障应用重启也不应该对其有任何影响。 二、死锁的产生及解决方法
产生死锁的四个必要条件
互斥条件进程对所分配的资源进行排他性控制即资源在一段时间内只能被一个进程使用。请求保持条件一个进程已经获得至少一个资源但又请求新的资源而该资源被其他进程占用导致该进程阻塞但已获得的资源保持不放。不可剥夺条件进程已获得的资源在未使用完之前不能被其他进程强行夺走只能由获得该资源的进程主动释放。环路等待条件存在一种循环等待资源的链链中每个进程已获得的资源同时被链中下一个进程请求形成循环等待。
数据库死锁产生的原因及解决方案
数据库死锁产生的原因有以下几点
多个事务同时访问同一资源每个事务都试图获取其他事务已经持有的锁导致互相等待从而产生死锁。12
事务在获取锁时的顺序不同也可能导致死锁。例如事务A获得了资源X的锁并尝试获取资源Y的锁而事务B获得了资源Y的锁并尝试获取资源X的锁。这种情况下两个事务都无法继续执行形成了死锁。4
解决数据库死锁的方案有以下几种 保持锁的顺序一致在多个事务请求资源的情况下保持锁的请求顺序一致可以避免死锁的发生。 尽量缩短事务的持有时间事务持有锁的时间过长会增加死锁的风险。因此在处理事务时应尽量缩短事务的持有时间尽快释放锁。 使用超时机制如果一个事务等待锁的时间过长可以使用超时机制来终止该事务从而避免死锁的发生。 检测并解决死锁数据库管理系统通常提供死锁检测机制一旦检测出死锁可以中止其中一个事务从而解除死锁。同时也可以优化锁的使用和重构事务来降低死锁的发生率。如果死锁频繁发生可能需要增加资源如提升服务器的处理能力或增加数据库的缓存空间。
三、事务的四种隔离级别 隔离级别脏读不可重复读幻读读未提交可能出现可能出现可能出现读已提交不会出现可能出现可能出现可重复读不会出现不会出现可能出现串行化不会出现不会出现不会出现 数据库事务的隔离级别有4种由低到高分别为Read uncommitted 、Read committed 、Repeatable read 、Serializable 。在事务的并发操作中可能会出现脏读不可重复读幻读。 0 .封锁协议 一级封锁协议读未提交:写加写锁读不加锁。事务T在修改数据R之前必须对其加X锁直到事务结束才释放。以及封锁协议可以防止修改丢失并保证事务T是可恢复的。在一级封锁协议中如果仅仅是读数据不对其进行修改是不需要加锁的所以它不能保证可重复读和不读“脏”数据。
二级封锁协议是读已提交:写加写锁读加临时锁。一级封锁协议加上事务T在读取数据R之前必须先对其加S锁读完后即可释放S锁。二级封锁协议除防止丢失修改还可进一步防止读“脏”数据。在二级封锁协议中由于读完数据即可释放S锁所以它不能保证可重复读。
三级封锁协议可重复读:写加写锁读加事务锁。一级封锁协议加上事务T在读取数据R之前必须先对其加S锁直到事务结束才释放。三级封锁协议可以防止丢失修改读“脏数据和不可重复读。
1 读未提交(Read uncommitted)
1.1 简述
一个事务读到了另一个事务还没有提交的数据。1.2 事例 父亲要给儿子转账。但是转账时父亲不小心按错了数字按成10万/月该钱已经打到儿子的账户但是事务还没有提交就在这时儿子去查看自己的储蓄卡发现转多了9万以为凭空多了9万非常高兴。但是父亲及时发现了不对马上回滚差点就提交了的事务将数字改成1万再提交。 1.3 分析 实际父亲给儿子转的还是1万但是儿子看到的是10万。儿子看到的是父亲还没提交事务时的数据。这就是脏读。 2. 读已提交(Read committed)
2.1 简述
一个事务要等另一个事务提交后才能读取数据。2.2 事例 儿子拿着父亲的信用卡去消费卡里目前有10当他买单时父亲事务开启收费系统事先检测到他的卡里有10万就在这个时候父亲要把钱全部转出充当家用并提交。当收费系统准备扣款时再检测卡里的金额发现已经没钱了第二次检测金额当然要等待父亲转出金额事务提交完。儿子就会很郁闷明明卡里是有钱的… 2.3 分析 这就是读已提交若有事务对数据进行更新操作时读操作事务要等待这个更新操作事务提交后才能读取数据可以解决脏读问题。但在这个事例中出现了一个事务范围内两次相同的查询却返回了不同数据这就是不可重复读。 3. 可重复读(Repeatable read)
3.1 简述
同一事务下事务在执行期间多次读取同一数据时能够保证读取到的数据是一致的。3.2 事例 儿子拿着信用卡去享受生活卡里只有10万当他买单时事务开启不允许其他事务的UPDATE修改操作收费系统事先检测到他的卡里有10万。这个时候父亲不能转出金额了。接下来收费系统就可以扣款了。 3.3 分析 可重复读解决了不可重复读的问题。说到这里应该明白的一点就是不可重复读对应的是修改即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入INSERT操作而不是UPDATE操作。 3.4 什么时候会出现幻读
3.4.1 简述
一个事务读取到了另一个事务新增的数据3.4.2 事例 儿子某一天去消费花了8千元然后他的父亲去查看他今天的消费记录全表扫描儿子事务开启看到确实是花了8千元就在这个时候儿子花了1万买了一部电脑即新增INSERT了一条消费记录并提交。当父亲打印儿子的消费记录清单时儿子事务提交发现花了1.8万元似乎出现了幻觉这就是幻读。 3.4.3 那怎么解决幻读问题
串行化4. 串行化(Serializable) 它是最高的事务隔离级别在该级别下事务串行化顺序执行可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率最低比较耗费数据库性能一般不推荐使用。 四、MVCCMulti-Version Concurrency Control
MVCC原理底层就是通过read view 以及undo log来实现
1 为什么会有MVCC
频繁加锁会导致数据库性能低下引入了MVCC多版本控制来实现读写不阻塞提高数据库性能在多版本并发控制中为了保证数据操作在多线程过程中保证事务隔离的机制降低锁竞争的压力保证较高的并发量。在每开启一个事务时会生成一个事务的版本号被操作的数据会生成一条新的数据行临时但是在提交前对其他事务是不可见的对于数据的更新包括增删改操作成功会将这个版本号更新到数据的行中事务提交成功将新的版本号更新到此数据行中这样保证了每个事务操作的数据都是互不影响的也不存在锁的问题。
MVCC机制的实现就是通过read-view机制与undo版本链比对机制使得不同的事务会根据数据版本链对比规则读取同一条数据在版本链上的不同版本数据。
2 MVCC在哪个隔离级别下才生效
MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作。其他两个隔离级别和MVCC不兼容因为 READ UNCOMMITTED 总是读取最新的数据行而不是符合当前事务版本的数据行。而 SERIALIZABLE 则会对所有读取的行都加锁。
InnoDB行数据默认隐藏列
InnoDB在每行数据都增加三个隐藏字段一个唯一行号一个记录创建的版本号一个记录回滚的版本号。
3 ReadView是什么
在我们平时执行一个事务的时候就会生成一个ReadViewReadView的组成结构大致如下
read view 参数解释
1.creator_trx_id: 当前事务id
没什么可解释就是当前事务ID2.m_ids:所有活跃事务的事务id
当前所有未提交的事务id构成的集合3.min_trx_id: m_ids里最小的事务id值
当前所有未提交的事务id构成的集合里的最小的哪个事务id4.max_trx_id: 最大事务id
下一个即将创建的事务idRead View快照的生成时机
repeatable read级别
语句级快照read committed级别
事务级的快照版本链比对规则
如果被访问版本的trx_id属性值与rv中的creator_trx_id值相同 可见如果被访问版本的trx_id属性值小于rv中的min_trx_id值 可见如果被访问版本的trx_id属性值大于或等于rv中的max_trx_id值 不可见如果被访问版本的trx_id属性值在rv的min_trx_id和max_trx_id之间 4.1 trx_id在m_ids中 不可见 4.2 trx_id不在m_ids中 可见
MVCC比对练习题 在同一个事务里针对id1的记录当前事务ID分别为200,99,38,15,5的行记录能查询到么是可见的么 200不可见、99可见、38可见、15不可见、5可见 思考题为啥要把最小的事务id值单独作为一个字段
时间复杂度难道要从所有未提交的集合中去找么依次遍历
1.版本说明
这里是8.0.332. 查询mysql全局事务隔离级别
2.1 查询命令
select global.transaction_isolation;2.2 默认隔离级别如下 3. 注意事项
低版本的查询语句是select global.tx_isolation; 五、不同隔离级别演示
演示准备
创建sql语句准备
CREATE TABLE user (--自增IDid INT NOT NULL AUTO_INCREMENT,--姓名name VARCHAR(50) NOT NULL,--年龄age INT NOT NULL,--主键PRIMARY KEY (id)
);数据准备
--插入一条记录id为1name为张三age为20
INSERT INTO user(id, name, age) VALUES (1, 张三, 20);
-- 插入一条记录id为2name为李四age为30
INSERT INTO user(id, name, age) VALUES (2, 李四, 30);
-- 插入一条记录id为3name为王五age为25
INSERT INTO user(id, name, age) VALUES (3, 王五, 25);
-- 插入一条记录id为4name为赵六age为28
INSERT INTO user(id, name, age) VALUES (4, 赵六, 28);读未提交-----脏读
设置当前会话隔离级别为读未提交 SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;1、a 事务(客户端1) 修改 、未提交 2、b事务客户端2 读该数据 3、a事务(客户端1) 回滚 4、b事务(客户端2) 再读该数据 和 2步不一致脏读 读已提交-----不可重复读
设置当前会话隔离级别为读已提交 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;1、a事务(客户端1) 修改 、未提交 2、b事务(客户端2) 读该数据 3、a事务(客户端1) 提交 4、b事务(客户端2) 读该数据 不可重复读 可重复读-----幻读
设置当前会话隔离级别为可重复读 SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;1、a 事务(客户端1) 修改、未提交 2、b 事务(客户端2) 读该数据 3、a 事务(客户端1) 提交 4、b 事务(客户端2) 读该数据 和之前一样可重复读 串行化
设置当前会话隔离级别为串行化 SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;1、a 事务(客户端1) 读取id 1的数据 2、b 事务(客户端2) 修改id 1的数据直接阻塞住 3、a 事务(客户端1) 提交 4、b 事务(客户端2) 获取行锁更新成功、串行执行 在InnoDB引擎下的的repeatable read (可重复复读)隔离级别下快照读MVCC影响下已经解决了幻读的问题
