-
补充： 下面的 头插法 只是针对于 找 最新的 数据库对象才成立！！！！！！
为什么不挂在屁股后面？因为如果这条链表上已经挤了 1000 个发生哈希冲突的表，要想挂在屁股后面，CPU 必须顺着指针把这 1000 个结构体全部遍历一遍才能找到“尾巴”，时间复杂度退化为 $O(N)$。 这是一个把数据结构从“书本理论”还原到“CPU 物理执行过程”的绝佳切入点！ 很多程序员背过“链表尾插法的时间复杂度是 ...
-
补充： 哈希表冲突的解决方法：案例
补充：破局：业务 B 自己也在别处建了一个 LOCK 结构体（代表表 99999），然后用一根链表指针（next），把自己挂在业务 A 的屁股后面！ 这是一个极其精准、直击 C 语言底层数据结构（指针操控）的核心追问！ 人类的直觉说出了“挂在业务 A 的屁股后面（尾插法）”。但在真实的 PostgreSQL 内核源码以及所有工业级 ...
-
postgresql数据库的 哈希表结构？推导
这是一个直接触及计算机科学（CS）数据结构灵魂的硬核追问！ 在人类的直觉里，找东西最快的方法是“按顺序找”或者“翻目录”。但在多核 CPU 面对每秒几十万次极速并发的内存寻址时，任何带有“遍历”性质的动作都是不可原谅的物理拖累。 为了实现绝对的 $O(1)$ 极速寻址，内核架构师没有选择普通的数组（Array），也 ...
-
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 万个行锁对象全塞进内存 ...