当前位置： 首页 > news >正文

MySQL——事务

news 2024/11/5 13:29:15

目录

一、事务的概念

二、事务提交方式

2.1 查看事务提交方式

三、原子性与一致性

3.1 创建测试表

3.2 验证事务开始与回滚

3.2.1 正常回滚

3.2.2 非正常退出--未commit，客户端崩溃，MySQL自动会回滚

​编辑

3.2.3 非正常退出--手动commit，客户端崩溃，但是数据被保留

​编辑四、模拟MVCC（delete update insert）

4.1 undo日志

4.2 3个记录隐藏列字段

4.3 模拟 MVCC

五、read view（select）

5.1 当前读与快照读

5.2 read view（隔离性）

一、事务的概念

我认为事务类似于C++中的加锁，特别是 std::unique_lock<std::mutex> ，我们可以使用两条 SQL 语句限定作用域，在这个作用域中可以有很多 SQL 语句，这些语句就是一个事物。

下面是一些比较官方的解释：

事务就是一组DML语句组成，这些语句在逻辑上存在相关性，这一组DML语句要么全部成功，要么全部失败，是一个整体。MySQL提供一种机制，保证我们达到这样的效果。事务还规定不同的客户端看到的数据是不相同的。

一个完整的事务，绝对不是简单的 sql 集合，还需要满足如下四个属性：

  • 原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

  • 一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。

  • 隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（ Readuncommitted ）、读提交（ read committed ）、可重复读（ repeatable read ）和串行化（ Serializable ）

  • 持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务

二、事务提交方式

  • 手动提交

  • 自动提交

2.1 查看事务提交方式

mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
1 row in set (0.04 sec)

可以使用 set 关闭自动提交

mysql> set autocommit=0;    # 0为off 1为on
Query OK, 0 rows affected (0.02 sec)mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | OFF   |
+---------------+-------+
1 row in set (0.00 sec)

三、原子性与一致性

-- 为了便于演示，我们将mysql的默认隔离级别设置成读未提交。
-- 具体操作我们后面专门会讲，现在已使用为主。
mysql> set global transaction isolation level READ UNCOMMITTED;
Query OK, 0 rows affected (0.00 sec)mysql> quit
Bye-- 需要重启终端，进行查看
mysql> select @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| READ-UNCOMMITTED        |
+-------------------------+
1 row in set (0.00 sec)

3.1 创建测试表

mysql> create table if not exists account(-> id int primary key,-> name varchar(50) not null default '',-> blance decimal(10,2) not null default 0.0-> )ENGINE=InnoDB DEFAULT CHARSET=UTF8;

3.2 验证事务开始与回滚

3.2.1 正常回滚

mysql> show variables like 'autocommit'; -- 故意开启自动提交
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
1 row in set (0.00 sec)mysql> begin; -- 事务的开始语句，也可以使用start transaction;
Query OK, 0 rows affected (0.00 sec)mysql> savepoint save1; -- 创建一个保存点save1
Query OK, 0 rows affected (0.01 sec)mysql> insert into account values (1, '张三', 33); -- 插入一条记录
Query OK, 1 row affected (0.06 sec)mysql> savepoint save2; -- 创建一个保存点save2
Query OK, 0 rows affected (0.00 sec)mysql> insert into account values (2, '李四', 44); -- 插入一条记录
Query OK, 1 row affected (0.00 sec)mysql> select * from account; -- 两条记录都在
+----+--------+--------+
| id | name   | blance |
+----+--------+--------+
|  1 | 张三   |  33.00 |
|  2 | 李四   |  44.00 |
+----+--------+--------+
2 rows in set (0.00 sec)mysql> rollback to save2; -- 回滚到保存点save2
Query OK, 0 rows affected (0.03 sec)mysql> select * from account; -- save2点的操作没了
+----+--------+--------+
| id | name   | blance |
+----+--------+--------+
|  1 | 张三   |  33.00 |
+----+--------+--------+
1 row in set (0.00 sec)mysql> insert into account values (2, '李四', 44); -- 重新插入李四
Query OK, 1 row affected (0.00 sec)mysql> select * from account;
+----+--------+--------+
| id | name   | blance |
+----+--------+--------+
|  1 | 张三   |  33.00 |
|  2 | 李四   |  44.00 |
+----+--------+--------+
2 rows in set (0.00 sec)mysql> rollback; -- 直接回滚，全部的插入都没了
Query OK, 0 rows affected (0.00 sec)mysql> select * from account;
Empty set (0.00 sec)

3.2.2 非正常退出--未commit，客户端崩溃，MySQL自动会回滚

3.2.3 非正常退出--手动commit，客户端崩溃，但是数据被保留

四、模拟MVCC（delete update insert）

4.1 undo日志

可以把undo日志理解为mysql中的内存缓冲区，用来保存日志数据，并在合适的时机，将内存中的缓存刷到磁盘中。

4.2 3个记录隐藏列字段

  • DB_TRX_ID ：6 byte，最近修改( 修改/插入 )事务ID，记录创建这条记录/最后一次修改该记录的事务ID

  • DB_ROLL_PTR : 7 byte，回滚指针，指向这条记录的上一个版本（简单理解成，指向历史版本就行，这些数据一般在 undo log 中）

  • DB_ROW_ID : 6 byte，隐含的自增ID（隐藏主键），如果数据表没有主键， InnoDB 会自动以DB_ROW_ID 产生一个聚簇索引

  • 补充：实际还有一个删除flag隐藏字段, 既记录被更新或删除并不代表真的删除，而是删除flag变了

mysql> create table if not exists student(-> name varchar(11) not null,-> age int not null-> );
Query OK, 0 rows affected (0.50 sec)mysql> insert into student values('张三', 28);
Query OK, 1 row affected (0.03 sec)mysql> select * from student;
+--------+-----+
| name   | age |
+--------+-----+
| 张三   |  28 |
+--------+-----+
1 row in set (0.00 sec)

使用以上SQL语句并插入数据，实际上的存储是如下模样：

4.3 模拟 MVCC

在进行修改时，mysql会发生写时拷贝，它会先将之前的数据（以下成为版本）拷贝一份放入undolog中，然后直接在当前版本上进行修改，修改后会使用DB_ROLL_PTR(回滚指针)指向undolog中上一版本的地址，以方便未来进行回滚：

上图是使用update进行数据更新，当使用delete时，实际上不是将数据删除，而是将其中的隐藏列字段的flag（4.2）设置为删除即可，所以它也可以形成版本。

使用insert时，因为`insert`是插入，也就是之前没有数据，那么`insert`也就没有历史版本。但是一般为了回滚操作，insert的数据也是要被放入undo log中，如果当前事务commit了，那么这个undo log 的历史insert记录就可以被清空了。

总结一下，也就是我们可以理解成，update和delete可以形成版本链，insert暂时不考虑

五、read view（select）

5.1 当前读与快照读

select读取，是读取最新的版本呢？还是读取历史版本？

  • 当前读：读取最新的记录，就是当前读。增删改，都叫做当前读，select也有可能当前读，比如：select lock in share mode(共享锁), select for update （这个好理解，我们后面不讨论）

  • 快照读：读取历史版本(一般而言)，就叫做快照读。(这个我们后面重点讨论)

当前读与快照读都有其特点：

  • 在多个事务同时删改查的时候，都是当前读，是要加锁的。那同时有select过来，如果也要读取最新版(当前读)，那么也就需要加锁，这就是串行化。

  • 但如果是快照读，读取历史版本的话，是不受加锁限制的。也就是可以并行执行！换言之，提高了效率，即MVCC的意义所在。

那么，是什么决定了，select是当前读，还是快照读呢？

隔离级别!

那为什么要有隔离级别呢？

事务都是原子的。所以，无论如何，事务总有先有后。

但是经过上面的操作我们发现，事务从begin->CURD->commit，是有一个阶段的。也就是事务有执行前，执行中，执行后的阶段。但，不管怎么启动多个事务，总是有先有后的，让不同的事务看到它该看到的内容，这就是所谓的隔离性与隔离级别要解决的问题。

先来的事务，应不应该看到后来的事务所做的修改呢?

5.2 read view（隔离性）

Read View 在 MySQL 源码中,就是一个类，本质是用来进行可见性判断的。当我们某个事务执行快照读的时候，对该记录创建一个 Read View 读视图，把它比作条件,用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的 undo log 里面的某个版本的数据。

class ReadView {
// 省略...
private:
/** 高水位，大于等于这个ID的事务均不可见*/
trx_id_t m_low_limit_id;
/** 低水位：小于这个ID的事务均可见 */
trx_id_t m_up_limit_id;
/** 创建该 Read View 的事务ID*/
trx_id_t m_creator_trx_id;
/** 创建视图时的活跃事务id列表*/
ids_t m_ids;
/** 配合purge，标识该视图不需要小于m_low_limit_no的UNDO LOG，
* 如果其他视图也不需要，则可以删除小于m_low_limit_no的UNDO LOG*/
trx_id_t m_low_limit_no;
/** 标记视图是否被关闭*/
bool m_closed;
// 省略...
};

read view是一个对象，它的值一旦初始化后，就不会再改变了（也就是取决于你执行 select 操作的时刻），以下是个更简化的源码：

m_ids; //一张列表，用来维护Read View生成时刻，系统正活跃的事务ID
up_limit_id; //记录m_ids列表中事务ID最小的ID
low_limit_id; //ReadView生成时刻系统尚未分配的下一个事务ID，也就是目前已出现过的事务ID的最大值+1
creator_trx_id //创建该ReadView的事务ID

也就是说，在并发执行事务时，下面假设一个场景：

https://e1p5hjol2cr.feishu.cn/sync/VEbOdYHiks9yOCbsnyCc6GlFnMk

  • 事务 ID 5、6、7、8 全部活跃。

  • 事务 5 创建 ReadView (执行select)后，事务 7 提交。

  • 事务 6 在事务 7 提交后再创建 ReadView

因为事务5在事务7提交前创建read view，所以它保存的成员以后不会改变，就算事务7提交后事务5再使用select，对事务7还是不可见。 但是事务6就不同了，事务6在事务7提交后创建read view，可以看到事务7的内容。 但是无论是事务5还是事务6，它们保存的up_limit_id其实都是不变的，那么事务6是如何检索到事务7呢？这就不简单是判断事物ID与up_limit_id，它会检索m_ids列表，在其中的则不可见，不在其中的则可见。

我们在实际读取数据版本链的时候，是能读取到每一个版本对应的事务ID的，即：当前记录的 DB_TRX_ID 。

如果当前读取版本的事务ID <= up_limit_id ，则说明要读取的事务已经被提交过了，应该被我们读到。反之，则不会读到该事务。但是经过上面的例子，我们也能体会到，其实mysql还会检索m_ids确认该事务是否已经被提交。


http://www.mrgr.cn/news/64681.html

相关文章：

  • 如何生成 PEM 格式的 SSH 密钥 ?
  • 单体架构的 IM 系统设计
  • 【Linux】- 权限（2）
  • 系统上云 - 挑战和成本最优
  • 滑动窗口习题篇(上)
  • 蓝桥杯 python day01 第一题
  • Redis安装与使用 + Springboot整合Redis
  • wpf中行为
  • 502 Bad Gateway 错误详解：从表现推测原因，逐步排查直至解决
  • IDEA2024下安装kubernetes插件并配置进行使用
  • 代理IP地址和端口是什么？怎么进行设置？
  • 达人探店和好友关注功能（feed流的使用，滚动分页查询）
  • Python 有哪些优雅的代码实现让自己的代码更pythonic？
  • 串口接收，不定长数据接收
  • 00 递推和递归的核心讲解
  • LeetCode27：移除元素
  • JavaEE进阶---第一个SprintBoot项目创建过程我的感受
  • 1.kubernetes作用及组件
  • （五）PostgreSQL数据库操作示例
  • 如何使用Python WebDriver爬取ChatGPT内容（完整教程）
  • 我为何要用wordpress搭建一个自己的独立博客
  • Linux基础 文件与目录
  • int a[5]里面的 a表示a[0], a执行包含5个整数的数组的指针
  • OTFS的基本原理(通俗易懂)
  • 如何建购物网站提升用户体验
  • Goland2024 最新激活码