书本上为什么这么说？（单一资源视角的逻辑）】 教材里说表锁不会死锁，是因为表锁把“粒度”提到了最高。 如果是行锁，进程 A 锁行 1，进程 B 锁行 2，两人互相去要对方的行，就会死锁。 但如果是纯粹的表锁，进程 A 直接把整张表霸占了，进程 B 连进都进不来，只能在表门口乖乖排队。因为没有了“微观交织”的 ...

这也是很多初学者在从业务开发转型底层 DBA 时，最容易卡住的认知盲区。因为在人类的直觉里，“锁”是挂在具体物品上的；既然有 1000 万个物品（数据行），就应该有 1000 万把锁。 但在 PostgreSQL 的工业级内核架构中，这根本不是魔法，而是一种极其冷酷的**“访问路径劫持（Access Path Hijacking）”与“状态降维”** ...

第一步工程绝境：内存爆仓与“锁升级”的诅咒 【他山之石的痛点】 在 MySQL (InnoDB) 或 SQL Server 中，行锁是维护在内存里的（类似一个哈希表）。 假设你要执行一句 UPDATE orders SET status = 'DONE' WHERE create_time < '2025-01-01';，这条语句命中了 5000 万行数据。 如果把 5000 万个行锁对象全塞进内存 ...