[pg]数据库的并发控制

参考

章 13. 并发控制

数据库并发事务控制四:postgresql数据库的锁机制二:表锁

PostgreSQL 事务处理和并发控制

PostgreSQL并发控制(MVCC, 事务,事务隔离级别)

数据库中Select For update语句的解析

PostgreSQL 之 锁机制

更高的并发:改进PostgreSQL锁机制

浅析postgresql数据库事务及行锁特征

PostgreSQL 之 锁的查看

– 演练实践
Postgresql 锁浅析

PostgreSQL 锁解密
PostgreSQL并发控制(显式锁定)

数据库的事务隔离与锁机制有什么差别和联系?

PostgreSQL 锁等待诊断详解

概要

pg文档介绍

下面内容摘自 pg文档:

13.3.1. 表级锁
下面的列表显示了可用的锁模式和PostgreSQL自动使用它们的场合。 你也可以用LOCK命令显式获得这些锁。请记住所有这些锁模式都是表级锁,即使它们的名字包含"row"单词(这些名称是历史遗产)。 在一定程度上,这些名字反应了每种锁模式的典型用法 — 但是语意却都是一样的。 两种锁模式之间真正的区别是它们有着不同的冲突锁模式集合(参考表 13-2)。 两个事务在同一时刻不能在同一个表上持有属于相互冲突模式的锁(但是,一个事务决不会和自身冲突。例如,它可以在同一个表上获得ACCESS EXCLUSIVE锁然后接着获取ACCESS SHARE锁)。非冲突锁模式可以由许多事务同时持有。 请特别注意有些锁模式是自冲突的(例如,在一个时刻ACCESS EXCLUSIVE锁不能被多于一个事务持有)而其他锁模式不是自冲突的(例如,ACCESS SHARE锁可以被多个事务持有)。

表级锁模式

ACCESS SHARE
只与ACCESS EXCLUSIVE锁模式冲突。

SELECT命令在被引用的表上获得一个这种模式的锁。通常,任何只读取表而不修改它的查询都将获得这种锁模式。

ROW SHARE
与EXCLUSIVE和ACCESS EXCLUSIVE锁模式冲突。

SELECT FOR UPDATE和SELECT FOR SHARE命令在目标表上取得一个这种模式的锁 (加上在被引用但没有选择FOR UPDATE/FOR SHARE的任何其他表上的ACCESS SHARE锁)。

ROW EXCLUSIVE
与SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE和ACCESS EXCLUSIVE锁模式冲突。

命令UPDATE、DELETE和INSERT在目标表上取得这种锁模式(加上在任何其他被引用表上的ACCESS SHARE锁)。通常,这种锁模式将被任何修改表中数据的命令取得。

SHARE UPDATE EXCLUSIVE
与SHARE UPDATE EXCLUSIVE、SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE和ACCESS EXCLUSIVE锁模式冲突。这种模式保护一个表不受并发模式改变和VACUUM运行的影响。

由VACUUM(不带FULL)、ANALYZE、CREATE INDEX CONCURRENTLY和ALTER TABLE VALIDATE以及其他ALTER TABLE的变体获得。

SHARE
与ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、SHARE ROW EXCLUSIVE、EXCLUSIVE和ACCESS EXCLUSIVE锁模式冲突。这种模式保护一个表不受并发数据改变的影响。

由CREATE INDEX(不带CONCURRENTLY)取得。

SHARE ROW EXCLUSIVE
与ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE和ACCESS EXCLUSIVE锁模式冲突。这种模式保护一个表不受并发数据修改所影响,并且是自排他的,这样在一个时刻只能有一个会话持有它。

由CREATE TRIGGER和很多 ALTER TABLE的很多形式所获得(见 ALTER TABLE)。

EXCLUSIVE
与ROW SHARE、ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE和ACCESS EXCLUSIVE锁模式冲突。这种模式只允许并发的ACCESS SHARE锁,即只有来自于表的读操作可以与一个持有该锁模式的事务并行处理。

由REFRESH MATERIALIZED VIEW CONCURRENTLY获得。

ACCESS EXCLUSIVE
与所有模式的锁冲突(ACCESS SHARE、ROW SHARE、ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE和ACCESS EXCLUSIVE)。这种模式保证持有者是访问该表的唯一事务。

由ALTER TABLE、DROP TABLE、TRUNCATE、REINDEX、CLUSTER、VACUUM FULL和REFRESH MATERIALIZED VIEW(不带CONCURRENTLY)命令获取。ALTER TABLE的很多形式也在这个层面上获得锁(见ALTER TABLE)。这也是未显式指定模式的LOCK TABLE命令的默认锁模式。

提示: 只有一个ACCESS EXCLUSIVE锁阻塞一个SELECT(不带FOR UPDATE/SHARE)语句。

一旦被获取,一个锁通常将被持有直到事务结束。 但是如果在建立保存点之后才获得锁,那么在回滚到这个保存点的时候将立即释放该锁。 这与ROLLBACK取消保存点之后所有的影响的原则保持一致。 同样的原则也适用于在PL/pgSQL异常块中获得的锁:一个跳出块的错误将释放在块中获得的锁。

在这里插入图片描述

摘录自 《PostgreSQL 锁解密》部分内容

原文: PostgreSQL 锁解密

表级锁
大多数的表级锁是由内置的 SQL 命令获得的,但他们也可以通过锁命令来明确获取。可使用的表级锁包括:

访问共享(ACCESS SHARE) - SELECT 命令可在查询中引用的表上获得该锁。一般规则是所有的查询中只有读表才获取此锁。

行共享(ROW SHARE) - SELECT FOR UPDATE 和 SELECT FOR SHARE 命令可在目标表上获得该锁(以及查询中所有引用的表的访问共享锁)。

行独占(ROW EXCLUSIVE) - UPDATE、INSERT 和 DELETE 命令在目标表上获得该锁(以及查询中所有引用的表的访问共享锁)。 一般规则是所有修改表的查询获得该锁。

共享更新独占(SHARE UPDATE EXCLUSIVE) - VACUUM(不含FULL),ANALYZE,CREATE INDEX CONCURRENTLY,和一些 ALTER TABLE 的命令获得该锁。

共享(SHARE) - CREATE INDEX 命令在查询中引用的表上获得该锁。

共享行独占(SHARE ROW EXCLUSIVE) - 不被任何命令隐式获取。

排他(EXCLUSIVE) - 这个锁模式在事务获得此锁时只允许读取操作并行。它不能由任何命令隐式获取。

访问独占(ACCESS EXCLUSIVE) - ALTER TABLE,DROP TABLE,TRUNCATE,REINDEX,CLUSTER 和 VACUUM FULL 命令在查询中引用的表上获得该锁。此锁模式是 LOCK 命令的默认模式。

重要的是要知道,所有这些锁都是表级锁,即使它们名称里有行(ROW)字。

每个锁模式的最重要的信息是与彼此冲突的模式列表。在同一时间同一个表中,2 个事务不能同时保持相冲突的锁模式。事务永远不会与自身发生冲突。 非冲突的锁可以支持多事务并发。同样重要的是要知道有的模式和自身冲突。一些锁模式在获得后会持续到事务结束。但如果锁是在建立一个保存点后获得,保存点回滚后锁会被立刻释放。 下面的表格展示了哪些模式是互相冲突的:

在这里插入图片描述

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
PostgreSQL(简称PG)和MySQL都是流行的开源关系型数据库管理系统。它们在设计、性能、功能和使用场景上有一些显著的差异: 1. **SQL标准支持**:PostgreSQL严格遵循SQL标准,对SQL92和后续标准的支持更全面,而MySQL虽然也支持大部分SQL,但在某些高级特性上可能不如PostgreSQL。 2. **可靠性与稳定性**:PostgreSQL以高可用性和一致性著称,常用于需要复杂事务处理和数据完整性要求高的应用。MySQL虽然也能提供稳定服务,但在一些情况下可能略逊一筹。 3. **性能**:MySQL通常在大量并发读写操作和简单的查询上表现更好,尤其是对于大型网站和在线游戏。PostgreSQL在复杂查询和分析任务上更为出色。 4. **扩展性和存储过程**:PostgreSQL支持存储过程和内建函数,以及更多的数据类型和复杂数据结构,如数组和JSON,使其更适合大数据和数据分析。MySQL在这方面相对简单。 5. **许可协议**:MySQL最初是闭源的,但后来被Oracle收购后变为商业版,而PostgreSQL始终坚持开放源代码,遵循GPLv2或更大的许可证。 6. **社区支持与生态系统**:MySQL由于其广泛的应用和商业支持,拥有庞大的开发者社区和丰富的第三方工具。PostgreSQL也有活跃社区,但规模相对较小。 7. **ACID事务支持**:PostgreSQL天生支持严格的ACID(原子性、一致性、隔离性、持久性)事务,而MySQL在InnoDB存储引擎下也提供了类似的保证,但不是所有版本都默认开启。 **相关问题**: 1. MySQL适合什么样的应用场景? 2. PostgreSQL如何优化复杂的查询性能? 3. 在数据安全性方面,两者有何不同策略?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值