进阶数据库系列（十四）：PostgreSQL 事务与并发控制

VIP文章 pgdba

已于 2023-10-13 22:49:36 修改

阅读量797

点赞数

分类专栏： PostgreSQL 文档文章标签：数据库 postgresql

于 2023-10-13 22:48:53 首次发布

本文链接：https://blog.csdn.net/pgdba/article/details/133819232

版权

前面介绍了 PostgreSQL 常用函数、锁操作、执行计划、视图与触发器、存储过程、索引、分区分表等相关的知识点，今天我将详细的为大家介绍 PostgreSQL 事务与并发控制相关知识，希望大家能够从中收获多多！如有帮助，请点在看、转发支持一波！！！

当多个事务并发执行时, 即使每个单独的事务都正确执行, 数据库的一致性也可能被破坏.。

为了控制并发事务之间的相互影响, 解决并发可能带来的数据不一致问题, 数据库的并发控制系统引入了基于锁的并发控制(Lock-Based Concurrency Control) 和基于多版本的并发控制机制 MVCC (Mult-Version。

事务是数据库系统执行过程中最小的逻辑单位。

当事务被提交时, 数据库管理系统要确保一个事务中的所有操作都成功完成, 并在数据库中永久保存; 如果一个事务中的一部分没有成功, 则系统会把数据库回滚到操作执行之前的状态。

原子性(Atomicity): 一个事务的所有操作, 要么全部执行, 要么全部不执行。
一致性(Consistency): 保证数据库从一个正确的状态(满足约束)到另一个正确的状态。
隔离性(Isolation): 事务并发执行时, 可能会交叉执行, 从而导致不一致的情况发生. 确保事务并发执行时, 每个事务都感觉不到有其他事务在并发的执行。
持久性(Durability): 一个事务完成后, 它对数据库的改变应该永久保存在数据库中。

这 4 个特性也称之为 ACID.

如果所有的事务都按照顺序执行, 那么执行时间就没有重叠交错, 也就不会有并发问题。

PostgreSQL 把事务并发导致的问题总结为:

脏读(Dirty read), 事务A 读取了事务B 已经修改但是还没有提交的数据。
不可重复读(Non-repeatable read), 事务A 读取了数据X; 然后事务B 修改了数据X 并提交; 然后事务A 再次读取数据X. 对于事务A来说, 两次读取结果不一致. 这种现象就是不可重复读。
幻读(Phantom read), 一个事务的两次执行相同的查询, 结果集数目不一致. 幻读可以认为是受 INSERT 和 DELETE 影响不可重复读的特例。
序列化异常(Serialization anomaly), 在可重复读情况下, 可能会出现序列化异常. 比如 X=1 事务A 执行 X++ 操作; 在事务A 提交之前, 事务B 修改 X=10 并提交成功; 由于事务A 是可重复读的, 事务A 看到的数据还是 X=1. 这就发生了序列化异常: 先执行事务A 和先执行事务B 的结果是不一样的。
更多关于 PostgreSQL 系列的学习文章，请参阅：PostgreSQL 数据库，本系列持续更新中。

为了避免事务与事务之间并发执行引发的副作用, 最简单的方法是串行地执行事务, 但是串行化会大幅降低系统吞吐量, 降低系统资源利用率。

为此, ANSI(American National Standards Institute, 美国国家标准学会) SQL 标准定义了 4 类事务隔离级别:

读未提交(Read Uncommitted): 所有事务都可以看到其他未提交事务的执行结果. 可以看到读未提交允许脏读发生, 脏读是非常危险的, 查询结果非常不可控, 所以读未提交事务隔离级别很少实际应用。
读已提交(Read Committed): 这是 PostgreSQL 默认的隔离级别, 它满足了一个事务只能看到已提交事务对关联数据所做的改变。
可重复读(Repeatable Read): 确保同一个事务在看到的数据内容是一致的。
可序列化(Serializable): 最高的隔离级别, 通过

关注