手机网站 jquery 特效,wordpress 压缩,中国万方官网,企业建站模板1. 事务的概念
事务是什么 在业务逻辑中使用sql#xff0c;面对一些较复杂的场景#xff0c;是需要多个sql语句组合起来实现的。如#xff1a;银行的转账业务#xff0c;若客户A要转账100元给客户B#xff0c;就要两条sql#xff1a;A余额减100#xff0c;B余额加100面对一些较复杂的场景是需要多个sql语句组合起来实现的。如银行的转账业务若客户A要转账100元给客户B就要两条sqlA余额减100B余额加100学生注册入学要向学校数据库中插入该学生的多条信息也要多sql组合完成。 事务 (Transcation) 的表层理解就是一组有逻辑关联的DML(data manipulation language)语句的集合。这里的逻辑是上层决定的通俗理解事务就是要完成的事情主要用于处理操作量大复杂度高的数据。
ACID特性 mysqld是一款网络服务器这就意味着同一时间可能会有多个客户端连接同一个mysqld那么数据就会存在并发访问的安全问题。因此事务还满足了四个特性以保证对数据操作的可靠性。 ACID四大特性
原子性 (Atomicity)一个事务要么做完要么不做不存在中间状态。如果事务执行在中间过程出现错误会回滚(Rollback)到最初状态在上层看来就好像这个事务从来没有执行过。一致性 (Consistency)事务开始前和结束后的状态必须是可确定的即事务必须按照预定的规则执行使得数据库从一个确定的状态变成另一个确定的状态保持数据库的完整性和准确性。隔离性 (Isolation)多个事务并发执行时一个事务的执行不会影响其它事务每一个事务都应该感觉自己在独立执行。持久性 (Durability)一旦事务提交其结果就应该永久保存到数据库中即使系统故障也不会丢失。
为什么有事务 MySQL设计之初并没有事务的概念而是使用了一段时间后设计者发现用户经常需要考虑并发操作数据库时的安全性和可靠性大大降低了开发效率。因此设计出了“事务”让MySQL自己保证可靠性。因此事务本质是为应用层服务的。 2. 事务的版本支持 MySQL中只有使用了innodb引擎的表或数据库支持事务操作 mysql show engines\G #查看数据库引擎的信息
*************************** 1. row ***************************Engine: InnoDBSupport: DEFAULTComment: Supports transactions, row-level locking, and foreign keys
Transactions: YES #InnoDB支持事务, 其它的都不支持XA: YESSavepoints: YES
#......
*************************** 4. row ***************************Engine: BLACKHOLESupport: YESComment: /dev/null storage engine (anything you write to it disappears)
Transactions: NOXA: NOSavepoints: NO
*************************** 5. row ***************************Engine: MyISAMSupport: YESComment: MyISAM storage engine
Transactions: NOXA: NOSavepoints: NO
#......3. 事务的基本操作
事务开始start transaction or begin设置保存点savepoint point_name回滚到某个保存点rollback to point_name回滚到事务初始时rollback事务结束提交事务commit 将begin到commit之间的所有sql操作视为一个整体这就是一个事务。 mysql select * from test;
---------------------
| id | name | balance |
---------------------
| 1 | 张伟 | 4396 |
| 2 | 子乔 | 1234.56 |
---------------------
2 rows in set (0.00 sec)mysql start transaction; #开始一个事务, begin也可以
Query OK, 0 rows affected (0.00 sec)mysql insert into test (name, balance) values (一菲, 8888);
Query OK, 1 row affected (0.00 sec)mysql savepoint s1; #设置保存点1后续可以回滚到此处
Query OK, 0 rows affected (0.00 sec)mysql select * from test;
---------------------
| id | name | balance |
---------------------
| 1 | 张伟 | 4396 |
| 2 | 子乔 | 1234.56 |
| 5 | 一菲 | 8888 |
---------------------
3 rows in set (0.00 sec)mysql delete from test where id2;
Query OK, 1 row affected (0.00 sec)mysql savepoint s2; #设置保存点2
Query OK, 0 rows affected (0.00 sec)mysql select * from test;
---------------------
| id | name | balance |
---------------------
| 1 | 张伟 | 4396 |
| 5 | 一菲 | 8888 |
---------------------
2 rows in set (0.00 sec)mysql insert into test (name, balance) values (小贤, 6767);
Query OK, 1 row affected (0.00 sec)mysql select * from test;
---------------------
| id | name | balance |
---------------------
| 1 | 张伟 | 4396 |
| 5 | 一菲 | 8888 |
| 6 | 小贤 | 6767 |
---------------------
3 rows in set (0.00 sec)mysql rollback to s2; #回滚到保存点2
Query OK, 0 rows affected (0.00 sec)mysql select * from test;
---------------------
| id | name | balance |
---------------------
| 1 | 张伟 | 4396 |
| 5 | 一菲 | 8888 |
---------------------
2 rows in set (0.00 sec)mysql rollback to s1; #回滚到保存点1
Query OK, 0 rows affected (0.00 sec)mysql select * from test;
---------------------
| id | name | balance |
---------------------
| 1 | 张伟 | 4396 |
| 2 | 子乔 | 1234.56 |
| 5 | 一菲 | 8888 |
---------------------
3 rows in set (0.00 sec)mysql rollback; #回滚到事务初始处
Query OK, 0 rows affected (0.00 sec)mysql select * from test;
---------------------
| id | name | balance |
---------------------
| 1 | 张伟 | 4396 |
| 2 | 子乔 | 1234.56 |
---------------------
2 rows in set (0.00 sec)mysql commit; #提交事务即该事务结束执行
Query OK, 0 rows affected (0.00 sec)
注意一条对InnoDB数据库进行操纵的sql语句会被打包成一个事务默认提交方式是自动提交用户可以修改为手动提交。一旦autocommit0从你执行一个sql语句到手动commit就是一个事务。
mysql select autocommit;
--------------
| autocommit |
--------------
| 1 |
--------------
1 row in set (0.00 sec)#autocommit自动提交默认为真设为0则不会自动提交需要用户手动提交事务mysql set autocommit0;
Query OK, 0 rows affected (0.00 sec)mysql select autocommit;
--------------
| autocommit |
--------------
| 0 |
--------------
1 row in set (0.00 sec)4. 事务的隔离性
事务的隔离性本质是为了防止事务并发运行中互相干扰让每一个事务都感觉自己在独立运行。 不同场景对隔离性的严格程度要求不同因此也衍生出了不同的隔离级别选择合适的隔离级别在事务并发控制中尤其重要。下面是MySQL中四种隔离级别
(1) 四个隔离级别 Read Uncommitted (读未提交): 最宽松的隔离级别两个事务并发运行时一个事务对数据库进行的所有写操作另一个事务都立即可见。读未提交的效率高但问题也比较多。引发问题脏读 (dirty read一个事务在执行过程中读到另一个事务更新且未提交的数据) Read Committed (读提交): 多个事务并发运行时若有进行更新数据update/insert/delete的事务在其commit之前其它事务不会读到该事务更新的数据只有其提交事务事务结束后其它事务才能读到。引发问题不可重复读non reapeatable read一个事务在执行时多次读取同一份数据结果不能保证相同 Repeatable Read (可重复读): InnoDB默认采用的隔离级别。一个事务从begin到commit的全过程中不会读取到其它事务更新的数据每次读取同一份数据都是相同的结果。只有在更新数据的事务commit之后begin的事务才能看到更新的数据。引发问题幻读 Serializable (串行化): 最严格的隔离级别同时代价最高对表的操作都需要加锁完成性能很低一般很少使用在该级别下事务互斥地、按顺序执行不仅可以避免脏读、不可重复读还避免了幻读。如下图左边事务执行中右边事务的insert语句阻塞
(2) 三个并发问题
脏读 脏读可以理解为事务读取到无效的、不合理的数据事务A在提交之前对数据的更新对于事务B来说是无效的因为此时事务A还没执行结束要把其视为一个整体这是事务的原子性决定的通常在业务逻辑层面会有影响。 假设现在有两个事务事务A和事务B他们对同一张表进行操作。事务B向表中插入一条记录若在read uncommitted隔离级别下事务A立马能看到B更新的数据。此时事务B因为某种原因出现故障中止执行回滚操作那么B先前更新的数据就是无效的。因此A读到了无效的数据甚至A浑然不知这是无效的数据并应用该数据会造成意想不到的后果。这就是脏读的危害。 脏读会在Read Uncommitted隔离级别下发生。 不可重复读 在Read Committed隔离级别下事务A执行中会在事务B提交后读取到事务B更新的数据导致事务A可能前后多次读取同一份数据的结果不同这就是不可重复读。不可重复读会对业务逻辑造成影响例如begin一个事务A对员工的工资区间进行划分中途如果有事务B对某个员工工资进行修改并在事务A结束前提交可能会导致事务A的执行出错。 幻读 如果使用锁机制来实现RR和RC这两种隔离级别在可重复读中该sql第一次读取到数据后就将这些数据加行锁其它事务无法修改这些数据就可以实现可重复读了。但这种方法却无法锁住insert的数据所以当事务A先前读取了数据或者修改了全部数据事务B还是可以insert数据提交这时事务A就会发现莫名其妙多了一条之前没有的数据这就是幻读不能通过行锁来避免。需要Serializable隔离级别 读用读锁写用写锁锁住整张表读锁和写锁互斥这么做可以有效的避免幻读、不可重复读、脏读等问题但会极大的降低数据库的并发能力。 MySQL中使用MVCC来避免幻读问题。 不可重复读和幻读有点类似都是前后多次读取结果不同。但不可重复读的重点是update和delete是对某一条现有数据的修改。而幻读的重点是insert是插入一条新的数据。
一些承上启下的理解 在实际应用中“可重复读”Repeatable Read隔离级别是相对较常见的选择。这是因为它在防止脏读Dirty Read和不可重复读Non-Repeatable Read的同时性能开销相对较小适用于大多数应用场景。 事务每次读取的数据都必须是最新的吗不一定想想事务本质是什么无非就是从事务begin到commit这一过程中对数据库中的数据做增删查改至于具体的就要由业务逻辑决定的。这一过程会被设为一个整体事务的原子性而事务对数据的读取也不一定是最新的也肯定不是最老的而应该是最合适的。 这就好比一个21级大学生从入学到毕业他在学校想要办各种事情如在学业方面上课、选课、转专业应该查看21级的培养方案不是最新的22级更不是20级、19级。甚至在生活方面住宿都只关心学校划分的21级的生活区域对于与自己无关的不关心。 对于事务而言最“合适”的数据就是事务begin时能看到的数据在Repeatable Read隔离级别下这份数据会被视为事务将要操作的数据从begin到commit整个过程中都不该受到其它事务对该数据更新的影响即使其它事务已commit事务会感觉只有自己在执行着任何增删改工作都是自己执行的所以读取数据也必然是合法的数据也能保证可重复读即不会有意料之外的数据变化所有的数据变化都是当前事务执行的。 5. MVCC多版本并发控制
数据库事务并发运行的场景有三种
读-读只读不会有问题读-写会有线程安全问题写-写会有线程安全问题要通过加锁解决
多版本并发访问MVCC, Multi-Version Concurrency Control用于解决事务读写并发冲突的无锁解决方法。MVCC的核心思想是在数据库中为每个事务保留多个版本的数据以允许不同事务同时读取和修改相同的数据而不会相互干扰。
事务ID与多版本记录 数据库表中的一行数据称为一条记录。 在数据库中活跃中的事务会被管理起来。先将事务描述为一个个的结构体对象再通过某种方式组织起来。其次因为MVCC的需要事务还会分配到一个ID这个ID是随时间戳而递增的。活跃事务的ID并不一定是连续的可能有些中途退出有些后续加入。事务的ID可能区分事务启动的先后顺序。 数据库中的每一条数据记录都会有三个隐藏列字段 DB_TRX_ID最近修改该记录的事务ID标记创建insert或最近一次修改update该数据记录的事务ID。大小6byte。DB_ROLL_PTR指向当前记录上一个历史版本的指针称为回滚指针DB_ROW_ID隐藏的自增主键若表没有设置主键InnoDB会用该隐藏主键创建索引。还有一个删除标记位Delete Mask。因为被删除的记录可能还会被恢复因此事务中delete数据是将删除标记位置为true恢复数据再置为false。 例如下面有一个简单的员工表他的一行数据记录实际记录的信息如下 idnamesalaryDB_TRX_IDDB_ROLL_PTRDB_ROW_ID1SMITH2000最近修改的事务ID回滚指针隐藏主键 MVCC为事务的每一次数据修改都保留一份历史版本历史版本数据保存在undo log缓冲区中是内存级的缓存数据为多版本并发控制而服务。 例如事务10ID为10的事务insert一条员工信息。以ID为主键那么此时隐藏主键就不需要了为空。并且由于是新插入的数据没有历史版本所以回滚指针也为空。 idnamesalaryDB_TRX_IDDB_ROLL_PTRDB_ROW_ID1SMITH200010NULLNULL 此时另一个事务ID为11将员工SMITH的工资改为1000数据被修改历史版本缓存到内存中。分为以下几个步骤这个过程是原子的 写操作必须先对本记录加行锁防止与其它并发事务产生冲突修改前先将历史版本拷贝到undo日志缓冲区中可以理解为是一种写时拷贝因为这个历史版本的数据可能别的事务要使用。备份历史数据后即可修改原生数据回滚指针指向历史副本数据上一个版本salary1000事务ID改为11。一切修改完毕释放行锁。 此时再有一个事务ID为12将员工SMITH的id改为2如下 MVCC将一条数据记录的多个历史版本穿成一条链表缓存在mysqld开辟的一段undo日志缓冲区中。 前面主要针对的是对数据的update操作而delete操作其实也可以看作是一次特殊的update因为只需修改Delete Mask标志位。
Read View 正确认识事务对于数据的读写。在MVCC中数据可以有多个版本的数据以允许不同事务同时读取和修改相同的数据而不会相互干扰。不同事务读取同一份数据产生不同的结果底层必然是读取不同的数据这个不同的数据就是历史版本链中的不同节点 对于事务的读操作每个事务都有一个特定的“数据可见范围”这个范围决定了事务在读取某一行记录时应该读取哪一个版本不应该读取哪一个版本。 对于事务的写操作每次修改的都是原生数据写入数据库的数据而不是内存中的历史版本历史版本只供读取使用解决事务的读写并发冲突。一个事务在修改数据时另一个事务要想读取不用阻塞等待而是读取合适的历史版本。 快照读在事务中如果其它事务正在修改数据对于普通的查询语句select不用加锁保护而是读取历史版本这种读取方式称为快照读每一个历史版本数据都称为一个快照。 当前读可以指定读当前最新版本的数据比如select lock in share mode(共享锁), select for update 这种情况需要加锁保护。
事务的启动有先有后不同事务看到不同的内容这恰恰就是事务隔离性决定的。在这个基础下如何决策事务应该看到多少内容哪些内容事务对于数据的可见性则是隔离级别决定的。
What is Read View
Read View本质就是用来判断事务的“数据可见范围”。Read View读视图决定了在MVCC中事务对于历史版本链中哪些可见哪些不可见。在MySQL中Read View是一个类对象每个事务关联一个Read View用以判断该事务的可见性。 Read View结构体的源代码中简化后的几个主要字段如下
class ReadView
{//省略...
private:ids_t m_ids; //创建视图时活跃的事务IDtrx_id_t m_up_limit_id; //低水位小于该ID的事务均可见trx_id_t m_low_limit_id; //高水位大于等于该ID的事务均不可见trx_id_t m_creator_trx_id //创建该ReadView的事务ID
}字段详解 m_ids一个集合记录创建ReadView时活跃的事务ID m_up_limit_id记录m_ids集合中最小的事务ID m_low_limit_id: 记录创建ReadView时系统尚未分配的下一个事务ID也就是目前已经出现过的最大ID1 m_creator_trx_id创建该ReadView的事务ID ReadView何时生成这里我们先统一认为是首次select时创建后面详解。 ReadView in MVCC
现在我们已经有了Read View读视图和版本链了接下来就可以真正认识到MVCC中是如何实现快照读的。快照读的本质就是当事务读取一条记录时遍历该记录的历史版本链根据自己的Read View找到符合读取条件的版本。 为事务创建一个ReadView可以理解为一次“快照”就像在那一瞬间为系统中活跃的事务拍下一张照片记录下它们的ID。 事务ID的大小可以区分事务的先后顺序因为事务ID是随时间增长的。 事务如何通过ReadView判断数据可见性呢见下图 快照形成Read View后面简称快照得到的m_ids列表是图中这些不一定连续的“小红点”因为在快照前可能有一些事务已经提交了不属于活跃事务导致m_ids的不连续。事务select数据时就会将数据的DB_TRX_ID(最近修改事务ID)和ReadView中的字段作对比查询条件 DR_TRX_ID up_limit_id表示最近修改这条记录的事务后面简称last事务在快照前已经提交了数据可见这个范围的ID在上图的最左区间 DR_TRX_ID creator_id, 表示last事务就是本事务那必然可见 DR_TRX_ID ∈[up_limit_id, low_limit_id) 分两种情况 DR_TRX_ID不在m_ids中表示last事务已经提交数据可见DR_TRX_ID在m_ids中表示last事务依然活跃随时可能再次修改数据数据不可见。 DR_TRX_ID low_limit_id, 表示last事务是快照之后新创建的事务数据不可见。
RR和RC的本质区别
RR (Repeated Read) 和 RC (Read Committed)两种隔离级别的本质区别实际上是ReadView读视图的创建方式不同
对于RR可重复读只有在首次select时快照创建一次ReadView直到事务提交都使用这个ReadView。ReadView始终不变事务对于数据的可见性也不变。对于RC读提交每次select都会更新一次ReadView即每次查询数据前都会更新数据可见性。 这样一来便很好理解两种隔离级别的现象。对于RR因为数据可见性始终不变所以即使快照时活跃的事务已经提交本事务也浑然不知始终将其视为活跃的事务其最新修改的数据对本事务不可见那么本事务每次select读取的结果都是一致的可重复读由此而来。而对于RC因为数据可见性每次查询前都会更新所以一旦历史快照过的事务已经提交再次select时就会将其ID从本事务ReadView的m_ids中去除其最新修改的数据本事务就可见了这就是为什么能够读提交。 总结MySQL数据库中为了实现事务并发控制updata、delete、insert这些写操作是需要加锁的锁的类型有很多如行锁、读锁写锁锁整张表、Next-Key锁。而select读操作与写操作并不冲突因为它是MVCC多版本并发控制实现的。这就是通过读写锁MVCC完成事务的隔离性。
