活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

# 并发控制介绍

## 基本概念

- 事务：构成单一逻辑工作单元的操作集合，这些操作要么全部执行成功，要么完全不执行。以保障数据操作的完整性。
- ACID：
 
 - 隔离性：事务间互不干扰，通过锁和隔离级别实现，例如转账过程中其他查询看不到中间状态。
 - 原子性：全部执行或全部不执行，通过回滚日志实现，例如转账的两个步骤必须同时成功或失败。
 - 持久性：提交后结果永久保存，通过日志先行 + 备份实现，例如转账成功后即使系统故障也不丢失。
 - 一致性：事务前后数据状态一致，通过约束检查实现，例如转账前后总金额不变。

## 并发控制

并发控制是多用户并发访问数据库时，保证数据完整性和一致性的关键技术。需要在效率提升和数据一致性之间寻求平衡。

数据库通常都会面临的是多个用户的多个事务同时来访问，为了效率它通常都会选择并发的去执行这些事务。这时候就会带来并发导致的一些问题，就是最终的执行结果可能不符合任何合理的业务逻辑顺序。比如说我们常见的有超卖的现象（例如，初始票数为 1 时，两个事务同时读取并出售，导致超卖，产生数据错误。），那么如果并发调度的结果不等价于任何一种先后顺序的执行结果，这个结果它就是错误的，我们这时候就要说明什么样的调度结果是正确的，这里就说到了串行调度，就是说我们多个事务它的执行顺序是依次执行的，那么它的结果一定是正确的。

调度类型可以分为串行调度和并发调度：

- 串行调度：依次执行，简单但效率低
- 并发调度：交替执行，效率高但可能出错

串行调度效率会很低，我们并发调度还有并发控制，就是要找出一种并发调度，它的结果与串行调度是等价的。

那么什么样的调度结果是等价的？这时候我们就要说明什么是冲突操作。

下面介绍这几种操作就是冲突操作：

1. 同一事物的里面的任意两个操作，它们的顺序是不可以改变的
2. 不同事物对同一数据的写操作，它们的顺序是不可以改变的
3. 不同事务对同一数据的读写操作，它们的顺序是不可以改变的

这个时候我们只需要找到一种并发调度的结果，他的冲突操作的顺序与串行调度的顺序是一致的，这时候我们找到的这个并发调度，它的结果就是正确的，我们也把这种调度称之为可串行化调度。

那么为了控制这些冲突操作的执行顺序，我们这里就要需要封锁技术。

# 封锁技术

## 必要性

解决并发问题，锁机制用于协调并发访问，防止多个事务同时操作数据导致的数据不一致。

## GBase 8s三种基本的锁的类型

- 共享锁（S锁）：允许多读，禁止写，就是我们常说的读锁
 允许多个事务同时读取资源，但禁止任何事务对资源进行修改，保证数据读取的一致性。
- 排他锁（X 锁）：禁止读写，就是我们常说的写锁
 一个事务独占资源，禁止其他任何事务读取或修改资源，保证数据修改的完整性。
- 提升锁（U 锁）：修改意向，可升级
 “预防性锁” ，表示事务有修改资源的意向，允许后续升级为排他锁，以保证修改操作的原子性。该锁的目的是避免“读后改”的死锁（S → X 升级死锁）

### 锁的兼容矩阵

| 请求锁/已有锁 | 无锁 | S锁 | U锁 | X锁 |
| --- | --- | --- | --- | --- |
| 请求S锁 | √ | √ | √ | × |
| 请求U锁 | √ | √ | × | × |
| 请求X锁 | √ | × | × | × |

## GBase 8s支持的锁的粒度

- 库级锁
- 表级锁：低并发，低开销
- 页面锁：并发性与开销的平衡
- 行级锁：高并发，高开销
- index-key锁：索引键锁，锁定索引，通过对两个索引上锁，同时锁定了这两个索引之间的索引，锁定的是一个范围区间，它不会允许其他的事务对当前索引键这个范围内进行修改操作

封锁粒度就说明的是一次加锁所覆盖的数据的范围大小，这其实是一个在并发能力和
锁管理成本之间权衡的一个结果，如果锁的粒度太大，那么它的并发能力就会很差，容易阻塞无关的事务；如果锁的粒度太小，那么带来的结果就是虽然它的并发度会变高，但是锁的数量就会非常的大，带来的锁的管理的成本就会变高。

### 锁粒度的操作

- 行级锁：
 ALTER TABLE tab1 LOCK MODE (ROW);
 CREATE TABLE tab1 (...) LOCK MODE ROW;
- 页面锁：
 ALTER TABLE tab1 LOCK MODE (PAGE);
 CREATE TABLE tab1 (...) LOCK MODE PAGE;
- 表级锁：
 
 - 自动上锁：访问表内数据的时候，数据库会默认的为这张表上锁，比如说读取数据时可能上的是读锁，也可能不对表上锁，但是它会防止其他的事务对表的结构进行修改
 - 手动上锁：
 BEGIN WORK;
 LOCK TABLE tab1 IN EXCLUSIVE MODE;
 LOCK TABLE tab2 IN SHARE MODE;
 UNLOCK TABLE tab1;
- 索引键锁：
 自动上锁，没办法主动使用，必须要有条件就是查询的表中必须要有索引，并且我们查询语句生成的执行计划必须要用到索引

### 锁粒度的选择

- 库锁：独占式，数据库维护锁，适用于需要独占数据库的维护场景。
- 表级锁：批量操作的并发控制手段，适用于批量更新和DDL操作等，可以有效避免并发冲突。
- 页级锁：兼顾并发与管理的选择，适用于顺序访问等场景。
- 行级锁：OLTP系统高并发利器，适合 OLTP 系统，通过仅锁定修改行来提升并发能力。
- 索引键锁：确保索引操作的完整性，Index-Key 锁是数据库在索引层面施加的锁，用于保护索引键值及其区间，防止并发事务插入或修改导致的幻读和一致性问题。

### 异常的锁等待情况

- 活锁：事务长时间等待，锁总是被其他事务抢先获取
 解决：先来先服务（FIFO）排队机制。
- 死锁：T1: LOCK R1 → 等待 R2；T2: LOCK R2 → 等待 R1
 产生条件：互斥、持有并等待、不可剥夺、循环等待。
 解决：预防和避免：破坏四个条件之一，资源分配图算法；检测与恢复：定期检测，选择牺牲者回滚。

### 锁演示

#### 行级锁

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/g7nVtAgk0X7Jv1oC8tNk2/image.png)

- HDR+S列表示锁类型，加了读锁，100002列表示资源的表号，此表是系统表，207是行号，所以第一行表示在100002系统表上207行加了读锁
- 第二行表示在10025b业务表上加了意向写的标志，并不是一把实际的锁，表示更低的层级中已经有写锁的存在了，0在这里表示整张表
- 第三行表示在10025b业务表上102行加了写锁

从上图可以看出，我们开启另外一个事务时，更新c1=1这行可以成功，因为c1=1并没有加锁

#### 页级锁

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/k_h0X-9p9FQ35_bOixInY/image.png)

与行级锁显示的类似，可以发现现在行号变成100，现在是使用的页级锁，表明锁定的是这张表中存储数据的某一页，同样更新c1=1发现锁超时

#### 索引键锁

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/2CdLwolcgFEYzsnDrPpKD/image.png)

我们需要先设置一下隔离级别为可重复读，因为可重复读的隔离级别才会使用读锁，这时候我们查询表中c1&gt;=1的内容，此时c1这一列上有索引，我们发现正常数据库的锁以及表锁，下面两个内容其实就是索引锁，后面K-1这里就
表示了它的锁的类型，103表示的是它锁定的第一行的数据，后面这一串f则表示它锁定的是一个无上界的区间，也就说明我们大于等于1的这一部分是不允许被修改的，包括插入，不可以插入在这个区间内的新的数据。所以我们另外的一个新的事务在执行insert语句的时候出现了锁超时的现象。

# 隔离级别

对写锁而言，只要是写操作无论如何都一定是会上锁的，而对于读锁，则要通过隔离级别的来进行控制。

对读锁的使用，在并行操作时会出现以下三个问题：

- 脏读：读取未提交的数据。
 事务T1修改了数据但尚未提交，事务T2读取了这些未提交的数据。如果T1随后回滚，T2读取到的数据就成为无效的“脏”数据。
- 幻读：结果集记录数变化
 事务T2按照特定条件检索数据。在T2未结束前，事务T1插入了符合T2查询条件的新记录，导致T2再次查询时结果集中出现新增。
- 不可重复读：事务内读取结果不一致
 在同一事务T2中，首次读取某数据后，事务T1修改并提交了该数据。结果是，事务T2再次读取该数据时，得到的结果与之前不同。

隔离级别就是为了明确哪些问题是被允许的，它代表的是数据库对不同并发异常的容忍程度，并且对应着不同的读锁的使用策略。

## GBase 8s提供的隔离级别

| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 加S锁 | 并发性 |
| --- | --- | --- | --- | --- | --- |
| dirty read | √ | √ | √ | 否 | 最高 |
| last committed read | × | √ | √ | 尝试但不加 | 高 |
| committed read | × | √ | √ | 尝试但不加 | 较高 |
| repeatable read | × | × | × | 对所有记录加 | 低 |

### dirty read脏读

脏读是最低的数据库隔离级别，允许事务读取其他事务尚未提交的数据，可能导致数据不一致。上面提到的三个并发问题都存在，所以在实际的应用场景中，很少直接使用脏读隔离级别，通常只在对数据一致性要求极低、只读事务或内部系统维护时考虑。

而对它的加锁机制，脏读隔离级别通常不使用任何显式的共享锁来防止脏读发生。读取时无锁，写入时排他锁不阻止其他事务读取。

大多数实际应用中，应选择读已提交、可重复读或串行化等更高级别的隔离级别，以确保数据的正确性。

**演示：**

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/5_fk4LK4FUcB9cPNFTolq/image.png)

### committed read读已提交

事务只能读取已提交的数据，不会读取到其他事务尚未提交的数据。这种隔离级别避免了脏读问题，保证读取数据的有效性，提高数据可靠性。但是存在不可重复读和幻读问题，可能导致事务内多次读取数据的不一致。适用于对数据一致性要求不高但需避免脏读的业务场景。

而它的加锁机制是，读取数据时只做锁检测，不加锁，更新数据时加行锁，事务提交后立即释放锁。

**演示：**

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/guMLaZ3gpXmHx0qOB6IHX/image.png)

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/-YqOqigmyoT4I3W48NCVY/image.png)

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/Na_ntGDjlnO0LUG0MZiOI/image.png)

### last committed read读最后提交（GBase 8s特有）

读最后提交是 GBase 8s 的一种隔离级别，读最后提交主要就是为了解决读操作被写操作阻塞的问题，也就是上面展示的锁超时以及死锁。事务会读取到已经提交的数据，若该行数据已经上锁，则会通过逻辑日志来读取上一版本的数据。需要注意的是它与MVCC版本控制是有区别的，它提供的并不是一个长时间保留的版本，只是通过逻辑日志去读取上一个版本，如果当前的事务提交，然后另一个事务又对数据进行修改时，那么刚才提交的数据就会成为上一个版本。

这种隔离级别适用于对数据一致性要求不高，但对并发性能要求较高的场景，如报表查询、数据分析等。

在读最后提交隔离级别下，同读已提交一样，读取数据时制作人锁检测，不施加任何锁，从而最大限度地提高并发性能。且该隔离级别只支持行级锁。

**演示：**

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/gLvoSOravLP-Ah8YJyMZg/image.png)

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/xPHHLwThDcCbb5riLNjGP/image.png)

### repeatable read可重复读

Repeatable Read 隔离级别，确保事务执行期间多次读取同一数据时，看到一致的数据版本，避免数据不一致。适用于对数据一致性要求高的场景，如财务、订单处理系统，避免数据错误和逻辑混乱。

共享锁机制：读取数据时获取共享锁，允许多个事务读取，但禁止修改或删除，直至事务结束。

排他锁机制：更新或删除数据时获取排他锁，阻止其他事务读取或修改，保证数据操作的原子性。

锁的持续时间：在整个事务期间持有共享锁，确保事务期间数据不被其他事务修改。

**演示：**

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/DivCl_lOU-dtouFjKOI4i/image.png)


## 默认隔离级别与监控

### 查看当前会话隔离级别

使用 `onstat -g SQL | awk '{print $1, $4}' | head - 20` 命令可以查看当前数据库会话的隔离级别。

### 默认隔离级别

| 库类型 | 默认隔离级别 |
| --- | --- | 
| 非日志数据库 | Dirty Read |
| 日志数据库 | Committed Read |
| 符合 ANSI 标准的数据库 | Repeatable Read |

# 参考视频

[【G 术时刻 18 期】GBase 8s 事务并发控制详解 P1-并发控制介绍\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV1Wt9rB9ET3/)

[【G 术时刻 18 期】GBase 8s 事务并发控制详解 P2-封锁技术\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV12n9rBtELZ/)

[【G 术时刻 18 期】GBase 8s 事务并发控制详解 P3-隔离级别\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV1Kn9rBbEQZ/)

GBase 8s事务并发控制介绍（原生模式）

GBase 8s事务并发控制介绍（原生模式）

评论

热门帖子