-
postgresql数据库的表锁,锁定粒度大,发生锁冲突概率最高,并发度最低
【排队论与碰撞域的物理推演】 什么是“粒度大”? 在 PG 里,表级锁的识别标志(LOCKTAG)是基于物理表的 OID 的。不管你这栋大厦里有 1000 万个房间(行),表锁就是直接把大厦的总大门给锁了。这就是粒度大。 2.为什么锁冲突概率最高?(碰撞域的极致收敛) 微观分散:如果用行锁,1 万个并发请求分 ...
-
PG 里的表级锁真的不会死锁吗?
书本上为什么这么说?(单一资源视角的逻辑)】 教材里说表锁不会死锁,是因为表锁把“粒度”提到了最高。 如果是行锁,进程 A 锁行 1,进程 B 锁行 2,两人互相去要对方的行,就会死锁。 但如果是纯粹的表锁,进程 A 直接把整张表霸占了,进程 B 连进都进不来,只能在表门口乖乖排队。因为没有了“微观交织”的 ...
-
为什么 一个结构体 LOCK 就可以 锁住含有千万行数据的表?
这也是很多初学者在从业务开发转型底层 DBA 时,最容易卡住的认知盲区。因为在人类的直觉里,“锁”是挂在具体物品上的;既然有 1000 万个物品(数据行),就应该有 1000 万把锁。 但在 PostgreSQL 的工业级内核架构中,这根本不是魔法,而是一种极其冷酷的**“访问路径劫持(Access Path Hijacking)”与“状态降维”** ...
-
postgresql数据库锁体系 之 行锁
第一步工程绝境:内存爆仓与“锁升级”的诅咒 【他山之石的痛点】 在 MySQL (InnoDB) 或 SQL Server 中,行锁是维护在内存里的(类似一个哈希表)。 假设你要执行一句 UPDATE orders SET status = 'DONE' WHERE create_time < '2025-01-01';,这条语句命中了 5000 万行数据。 如果把 5000 万个行锁对象全塞进内存 ...