漳州找人做网站要求哪些,wordpress页面点赞,网站海外推广服务,网站建设服务协议书ACID 特性
在关系型数据库管理系统中#xff0c;一个逻辑工作单元要成为事务#xff0c;必须满足这 4 个特性#xff0c;即所谓的 ACID#xff1a; 原子性#xff08;Atomicity#xff09;、一致性#xff08;Consistency#xff09;、隔离性#xff08;Isolation一个逻辑工作单元要成为事务必须满足这 4 个特性即所谓的 ACID 原子性Atomicity、一致性Consistency、隔离性Isolation和持久性Durability。
原子性
原子性事务是一个原子操作单元其对数据的修改要么全都执行要么全都不执行。 修改—》Buffer Pool修改—》刷盘。可能会有下面两种情况
事务提交了如果此时Buffer Pool的脏页没有刷盘如何保证修改的数据生效 Redo如果事务没提交但是Buffer Pool的脏页刷盘了如何保证不该存在的数据撤销Undo
每一个写事务都会修改BufferPool从而产生相应的Redo/Undo日志在Buffer Pool 中的页被刷到 磁盘之前这些日志信息都会先写入到日志文件中如果 Buffer Pool 中的脏页没有刷成功此时数据 库挂了那在数据库再次启动之后可以通过 Redo 日志将其恢复出来以保证脏页写的数据不会丢 失。如果脏页刷新成功此时数据库挂了就需要通过Undo来实现了。
持久性
**持久性**指的是一个事务一旦提交它对数据库中数据的改变就应该是永久性的后续的操作或故障不 应该对其有任何影响不会丢失。 如下图所示一个“提交”动作触发的操作有binlog落地、发送binlog、存储引擎提交、flush_logs check_point、事务提交标记等。这些都是数据库保证其数据完整性、持久性的手段。 MySQL的持久性也与WAL技术相关redo log在系统Crash重启之类的情况时可以修复数据从而保 障事务的持久性。通过原子性可以保证逻辑上的持久性通过存储引擎的数据刷盘可以保证物理上的持 久性。
隔离性
**隔离性**指的是一个事务的执行不能被其他事务干扰即一个事务内部的操作及使用的数据对其他的并 发事务是隔离的。 InnoDB 支持的隔离性有 4 种隔离性从低到高分别为读未提交、读提交、可重复读、可串行化。锁 和多版本控制MVCC技术就是用于保障隔离性的。
一致性
一致性指的是事务开始之前和事务结束之后数据库的完整性限制未被破坏。一致性包括两方面的内 容分别是约束一致性和数据一致性。 **约束一致性**创建表结构时所指定的外键、Check、唯一索引等约束可惜在 MySQL 中不支持 Check 。 **数据一致性**是一个综合性的规定因为它是由原子性、持久性、隔离性共同保证的结果而不是 单单依赖于某一种技术。 一致性也可以理解为数据的完整性。数据的完整性是通过原子性、隔离性、持久性来保证的而这3个 特性又是通过 Redo/Undo 来保证的。逻辑上的一致性包括唯一索引、外键约束、check 约束这属 于业务逻辑范畴。 ACID 及它们之间的关系如下图所示4个特性中有3个与 WAL 有关系都需要通过 Redo、Undo 日志 来保证等。 WAL的全称为Write-Ahead Logging先写日志再写磁盘。 事务控制的演进
并发事务
事务并发处理可能会带来一些问题比如更新丢失、脏读、不可重复读、幻读等。 更新丢失 当两个或多个事务更新同一行记录会产生更新丢失现象。可以分为回滚覆盖和提交覆盖。 回滚覆盖一个事务回滚操作把其他事务已提交的数据给覆盖了。 提交覆盖一个事务提交操作把其他事务已提交的数据给覆盖了。 脏读 一个事务读取到了另一个事务修改但未提交的数据。 不可重复读 一个事务中多次读取同一行记录不一致后面读取的跟前面读取的不一致。 幻读 一个事务中多次按相同条件查询结果不一致。后续查询的结果和面前查询结果不同多了或少了 几行记录。
排队
最简单的方法就是完全顺序执行所有事务的数据库操作不需要加锁简单的说就是全局排队。序列 化执行所有的事务单元数据库某个时刻只处理一个事务操作特点是强一致性处理性能低。 排他锁
引入锁之后就可以支持并发处理事务如果事务之间涉及到相同的数据项时会使用排他锁或叫互斥 锁先进入的事务独占数据项以后其他事务被阻塞等待前面的事务释放锁。 注意在整个事务1结束之前锁是不会被释放的所以事务2必须等到事务1结束之后开始。
读写锁
读和写操作读读、写写、读写、写读。 读写锁就是进一步细化锁的颗粒度区分读操作和写操作让读和读之间不加锁这样下面的两个事务 就可以同时被执行了。 读写锁可以让读和读并行而读和写、写和读、写和写这几种之间还是要加排他锁。
MVCC
多版本控制MVCC也就是Copy on Write的思想。MVCC除了支持读和读并行还支持读和写、写和读 的并行但为了保证一致性写和写是无法并行的。
在事务1开始写操作的时候会copy一个记录的副本其他事务读操作会读取这个记录副本因此不会影 响其他事务对此记录的读取实现写和读并行。 MVCC概念 MVCCMulti Version Concurrency Control被称为多版本控制是指在数据库中为了实现高并发的 数据访问对数据进行多版本处理并通过事务的可见性来保证事务能看到自己应该看到的数据版本。 多版本控制很巧妙地将稀缺资源的独占互斥转换为并发大大提高了数据库的吞吐量及读写性能。 如何生成的多版本每次事务修改操作之前都会在Undo日志中记录修改之前的数据状态和事务号 该备份记录可以用于其他事务的读取也可以进行必要时的数据回滚。 MVCC实现原理 MVCC最大的好处是读不加锁读写不冲突。在读多写少的系统应用中读写不冲突是非常重要的极 大的提升系统的并发性能这也是为什么现阶段几乎所有的关系型数据库都支持 MVCC 的原因不过目 前MVCC只在 Read Commited 和 Repeatable Read 两种隔离级别下工作。 在 MVCC 并发控制中读操作可以分为两类: 快照读Snapshot Read与当前读 Current Read。
快照读读取的是记录的快照版本有可能是历史版本不用加锁。select当前读读取的是记录的最新版本并且当前读返回的记录都会加锁保证其他事务不会再并发 修改这条记录。select… for update 或lock in share modeinsert/delete/update
为了让大家更直观地理解 MVCC 的实现原理举一个记录更新的案例来讲解 MVCC 中多版本的实现。 假设 F1F6 是表中字段的名字16 是其对应的数据。后面三个隐含字段分别对应该行的隐含ID、事 务号和回滚指针如下图所示。 具体的更新过程如下 假如一条数据是刚 INSERT 的DB_ROW_ID 为 1其他两个字段为空。当事务 1 更改该行的数据值 时会进行如下操作如下图所示。 用排他锁锁定该行记录 Redo log 把该行修改前的值复制到 Undo log即图中下面的行 修改当前行的值填写事务编号使回滚指针指向 Undo log 中修改前的行。
接下来事务2操作过程与事务 1 相同此时 Undo log 中会有两行记录并且通过回滚指针连在一 起通过当前记录的回滚指针回溯到该行创建时的初始内容如下图所示。
[图片上传失败…(image-24653d-1625379524706)]
MVCC已经实现了读读、读写、写读并发处理如果想进一步解决写写冲突可以采用下面两种方案
乐观锁悲观锁
事务隔离级别
隔离级别类型
前面提到的“更新丢失”、”脏读”、“不可重复读”和“幻读”等并发事务问题其实都是数据库一致性问题 为了解决这些问题MySQL数据库是通过事务隔离级别来解决的数据库系统提供了以下 4 种事务隔 离级别供用户选择。 读未提交 Read Uncommitted 读未提交解决了回滚覆盖类型的更新丢失但可能发生脏读现象也就是 可能读取到其他会话中未提交事务修改的数据。 已提交读 Read Committed 读已提交只能读取到其他会话中已经提交的数据解决了脏读。但可能发生 不可重复读现象也就是可能在一个事务中两次查询结果不一致。 可重复读 Repeatable Read 可重复读解决了不可重复读它确保同一事务的多个实例在并发读取数据 时会看到同样的数据行。不过理论上会出现幻读简单的说幻读指的的当用户读取某一范围的数 据行时另一个事务又在该范围插入了新行当用户在读取该范围的数据时会发现有新的幻影行。 可串行化 Serializable 串行化所有的增删改查串行执行。它通过强制事务排序解决相互冲突从而解决 幻度的问题。这个级别可能导致大量的超时现象的和锁竞争效率低下。
数据库的事务隔离级别越高并发问题就越小但是并发处理能力越差代价。读未提交隔离级别最 低并发问题多但是并发处理能力好。以后使用时可以根据系统特点来选择一个合适的隔离级别 比如对不可重复读和幻读并不敏感更多关心数据库并发处理能力此时可以使用Read Commited隔 离级别。 事务隔离级别针对Innodb引擎支持事务的功能。像MyISAM引擎没有关系。 事务隔离级别和锁的关系 1事务隔离级别是SQL92定制的标准相当于事务并发控制的整体解决方案本质上是对锁和MVCC使 用的封装隐藏了底层细节。 2锁是数据库实现并发控制的基础事务隔离性是采用锁来实现对相应操作加不同的锁就可以防 止其他事务同时对数据进行读写操作。 3对用户来讲首先选择使用隔离级别当选用的隔离级别不能解决并发问题或需求时才有必要在 开发中手动的设置锁。 MySQL默认隔离级别可重复读 Oracle、SQLServer默认隔离级别读已提交 一般使用时建议采用默认隔离级别然后存在的一些并发问题可以通过悲观锁、乐观锁等实现处 理。
MySQL隔离级别控制
MySQL默认的事务隔离级别是Repeatable Read查看MySQL当前数据库的事务隔离级别命令如下 show variables like tx_isolation;或 select tx_isolation; 设置事务隔离级别可以如下命令 SQLset tx_isolationREAD-UNCOMMITTED;
set tx_isolationREAD-COMMITTED;
set tx_isolationREPEATABLE-READ;
set tx_isolationSERIALIZABLE;锁机制和实战
锁分类
在 MySQL中锁有很多不同的分类。 从操作的粒度可分为表级锁、行级锁和页级锁。 表级锁每次操作锁住整张表。锁定粒度大发生锁冲突的概率最高并发度最低。应用在 MyISAM、InnoDB、BDB 等存储引擎中。 行级锁每次操作锁住一行数据。锁定粒度最小发生锁冲突的概率最低并发度最高。应 用在InnoDB 存储引擎中。 页级锁每次锁定相邻的一组记录锁定粒度界于表锁和行锁之间开销和加锁时间界于表 锁和行锁之间并发度一般。应用在BDB 存储引擎中。 从操作的类型可分为读锁和写锁。 读锁S锁共享锁针对同一份数据多个读操作可以同时进行而不会互相影响。 写锁X锁排他锁当前写操作没有完成前它会阻断其他写锁和读锁。
IS锁、IX锁意向读锁、意向写锁属于表级锁S和X主要针对行级锁。在对表记录添加S或X锁之 前会先对表添加IS或IX锁。 S锁事务A对记录添加了S锁可以对记录进行读操作不能做修改其他事务可以对该记录追加 S锁但是不能追加X锁需要追加X锁需要等记录的S锁全部释放。 X锁事务A对记录添加了X锁可以对记录进行读和修改操作其他事务不能对记录做读和修改操 作。 从操作的性能可分为乐观锁和悲观锁。 乐观锁一般的实现方式是对记录数据版本进行比对在数据更新提交的时候才会进行冲突 检测如果发现冲突了则提示错误信息。 悲观锁在对一条数据修改的时候为了避免同时被其他人修改在修改数据之前先锁定 再修改的控制方式。共享锁和排他锁是悲观锁的不同实现但都属于悲观锁范畴。
行锁原理
在InnoDB引擎中我们可以使用行锁和表锁其中行锁又分为共享锁和排他锁。InnoDB****行锁是通过对 索引数据页上的记录加锁实现的主要实现算法有 3 种Record Lock、Gap Lock 和 Next-key Lock。 RecordLock锁锁定单个行记录的锁。记录锁RC、RR隔离级别都支持 GapLock锁间隙锁锁定索引记录间隙确保索引记录的间隙不变。范围锁RR隔离级别支 持 Next-key Lock 锁记录锁和间隙锁组合同时锁住数据并且锁住数据前后范围。记录锁范 围锁RR隔离级别支持
在RR隔离级别InnoDB对于记录加锁行为都是先采用Next-Key Lock但是当SQL操作含有唯一索引 时Innodb会对Next-Key Lock进行优化降级为RecordLock仅锁住索引本身而非范围。 select … from 语句InnoDB引擎采用MVCC机制实现非阻塞读所以对于普通的select语句 InnoDB不加锁 select … from lock in share mode语句追加了共享锁InnoDB会使用Next-Key Lock锁进行处 理如果扫描发现唯一索引可以降级为RecordLock锁。 select … from for update语句追加了排他锁InnoDB会使用Next-Key Lock锁进行处理如果扫 描发现唯一索引可以降级为RecordLock锁。 update … where 语句InnoDB会使用Next-Key Lock锁进行处理如果扫描发现唯一索引可以 降级为RecordLock锁。 delete … where 语句InnoDB会使用Next-Key Lock锁进行处理如果扫描发现唯一索引可以降 级为RecordLock锁。 insert语句InnoDB会在将要插入的那一行设置一个排他的RecordLock锁。
下面以“update t1 set name‘XX’ where id10”操作为例举例子分析下 InnoDB 对不同索引的加锁行 为以RR隔离级别为例。
主键加锁 加锁行为仅在id10的主键索引记录上加X锁。
唯一键加锁 加锁行为现在唯一索引id上加X锁然后在id10的主键索引记录上加X锁。
非唯一键加锁 加锁行为对满足id10条件的记录和主键分别加X锁然后在(6,c)-(10,b)、(10,b)-(10,d)、(10,d)- (11,f)范围分别加Gap Lock。
无索引加锁 加锁行为表里所有行和间隙都会加X锁。当没有索引时会导致全表锁定因为InnoDB引擎 锁机制是基于索引实现的记录锁定。【白嫖资料】
悲观锁
悲观锁Pessimistic Locking是指在数据处理过程将数据处于锁定状态一般使用数据库的锁机 制实现。从广义上来讲前面提到的行锁、表锁、读锁、写锁、共享锁、排他锁等这些都属于悲观锁 范畴。 表级锁 表级锁每次操作都锁住整张表并发度最低。常用命令如下 手动增加表锁 lock table 表名称 read|write,表名称2 read|write; 查看表上加过的锁 show open tables; 删除表锁 unlock tables; 表级读锁当前表追加read锁当前连接和其他的连接都可以读操作但是当前连接增删改操作 会报错其他连接增删改会被阻塞。 表级写锁当前表追加write锁当前连接可以对表做增删改查操作其他连接对该表所有操作都 被阻塞包括查询。 总结表级读锁会阻塞写操作但是不会阻塞读操作。而写锁则会把读和写操作都阻塞。 共享锁行级锁-读锁 共享锁又称为读锁简称S锁。共享锁就是多个事务对于同一数据可以共享一把锁都能访问到数 据但是只能读不能修改。使用共享锁的方法是在select … lock in share mode只适用查询语 句。 总结事务使用了共享锁读锁只能读取不能修改修改操作被阻塞。 排他锁行级锁-写锁 排他锁又称为写锁简称X锁。排他锁就是不能与其他锁并存如一个事务获取了一个数据行的排 他锁其他事务就不能对该行记录做其他操作也不能获取该行的锁。【白嫖资料】 使用排他锁的方法是在SQL末尾加上for updateinnodb引擎默认会在updatedelete语句加上 for update。行级锁的实现其实是依靠其对应的索引所以如果操作没用到索引的查询那么会锁 住全表记录。
总结事务使用了排他锁写锁当前事务可以读取和修改其他事务不能修改也不能获取记录 锁select… for update。如果查询没有使用到索引将会锁住整个表记录。
乐观锁
乐观锁是相对于悲观锁而言的它不是数据库提供的功能需要开发者自己去实现。在数据库操作时 想法很乐观认为这次的操作不会导致冲突因此在数据库操作时并不做任何的特殊处理即不加锁 而是在进行事务提交时再去判断是否有冲突了。 乐观锁实现的关键点冲突的检测。 悲观锁和乐观锁都可以解决事务写写并发在应用中可以根据并发处理能力选择区分比如对并发率要 求高的选择乐观锁对于并发率要求低的可以选择悲观锁。 乐观锁实现原理 使用版本字段version 先给数据表增加一个版本(version) 字段每操作一次将那条记录的版本号加 1。version 是用来查看被读的记录有无变化作用是防止记录在业务处理期间被其他事务修改。 使用时间戳Timestamp 与使用version版本字段相似同样需要给在数据表增加一个字段字段类型使用timestamp 时间戳。也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳 进行对比如果一致则提交更新否则就是版本冲突取消操作。 乐观锁案例 下面我们使用下单过程作为案例描述下乐观锁的使用。 第一步查询商品信息 select (quantity,version) from products where id1; 第二部根据商品信息生成订单 insert into orders ...insert into items ... 第三部修改商品库存 update products set quantityquantity-1,versionversion1where id1 and version#{version};
除了自己手动实现乐观锁之外许多数据库访问框架也封装了乐观锁的实现比如 hibernate框架。MyBatis框架大家可以使用OptimisticLocker插件来扩展。【白嫖资料】
死锁与解决方案
下面介绍几种常见的死锁现象和解决方案
表锁死锁 产生原因 用户A访问表A锁住了表A然后又访问表B另一个用户B访问表B锁住了表B然后企图 访问表A这时用户A由于用户B已经锁住表B它必须等待用户B释放表B才能继续同样用户B要 等用户A释放表A才能继续这就死锁就产生了。 用户A–》A表表锁–》B表表锁 用户B–》B表表锁–》A表表锁
解决方案 这种死锁比较常见是由于程序的BUG产生的除了调整的程序的逻辑没有其它的办法。仔细分 析程序的逻辑对于数据库的多表操作时尽量按照相同的顺序进行处理尽量避免同时锁定两个 资源如操作A和B两张表时总是按先A后B的顺序处理 必须同时锁定两个资源时要保证在任 何时刻都应该按照相同的顺序来锁定资源。
行级锁死锁 产生原因1 如果在事务中执行了一条没有索引条件的查询引发全表扫描把行级锁上升为全表记录锁定等 价于表级锁多个这样的事务执行后就很容易产生死锁和阻塞最终应用系统会越来越慢发 生阻塞或死锁。 解决方案1 SQL语句中不要使用太复杂的关联多表的查询使用explain“执行计划对SQL语句进行分析对于 有全表扫描和全表锁定的SQL语句建立相应的索引进行优化。 产生原因2 两个事务分别想拿到对方持有的锁互相等待于是产生死锁。
解决方案2 在同一个事务中尽可能做到一次锁定所需要的所有资源【白嫖资料】 按照id对资源排序然后按顺序进行处理 共享锁转换为排他锁
产生原因 事务A 查询一条纪录然后更新该条纪录此时事务B 也更新该条纪录这时事务B 的排他锁由于 事务A 有共享锁必须等A 释放共享锁后才可以获取只能排队等待。事务A 再执行更新操作时 此处发生死锁因为事务A 需要排他锁来做更新操作。但是无法授予该锁请求因为事务B 已经 有一个排他锁请求并且正在等待事务A 释放其共享锁。
事务A: select * from dept where deptno1 lock in share mode; //共享锁,1update dept set dnamejava where deptno1;//排他锁,3 事务B: update dept set dnameJava where deptno1;//由于1有共享锁没法获取排他锁需等待2
解决方案 对于按钮等控件点击立刻失效不让用户重复点击避免引发同时对同一条记录多次操 作 使用乐观锁进行控制。乐观锁机制避免了长事务中的数据库加锁开销大大提升了大并发量 下的系统性能。需要注意的是由于乐观锁机制是在我们的系统中实现来自外部系统的用 户更新操作不受我们系统的控制因此可能会造成脏数据被更新到数据库中 死锁排查 MySQL提供了几个与锁有关的参数和命令可以辅助我们优化锁操作减少死锁发生。 查看死锁日志 通过show engine innodb status\G命令查看近期死锁日志信息。 使用方法1、查看近期死锁日志信息2、使用explain查看下SQL执行计划 查看锁状态变量 通过show status like’innodb_row_lock%‘命令检查状态变量分析系统中的行锁的争夺 情况 Innodb_row_lock_current_waits当前正在等待锁的数量 Innodb_row_lock_time从系统启动到现在锁定总时间长度 Innodb_row_lock_time_avg 每次等待锁的平均时间 Innodb_row_lock_time_max从系统启动到现在等待最长的一次锁的时间 Innodb_row_lock_waits系统启动后到现在总共等待的次数
如果等待次数高而且每次等待时间长需要分析系统中为什么会有如此多的等待然后着 手定制优化。
最后祝大家早日学有所成拿到满意offer
