PostgreSQL

当你在PostgreSQL中执行了一万次UPDATE操作后，可能会发现一个令人困惑的现象：表的数据行数没变，但磁盘占用却增长了好几倍。更奇怪的是，即使你执行了DELETE删除了大量数据，磁盘空间也没有减少。 ...

1970年代，当第一个关系数据库系统还在襁褓中时，工程师们就面临一个根本性的矛盾：内存速度快但易失，磁盘可靠但缓慢。一个事务提交后，如何保证数据在断电瞬间不会丢失？如何让数据库在崩溃后能快速恢复到一致状态？这些问题的答案，催生了数据库领域最基础也最精妙的设计——预写日志（Write-Ahead Log，WAL）与检查点（Checkpoint）机制。 ...

1981年，加州大学伯克利分校的Michael Stonebraker发表了一篇标题平实却影响深远的论文——《Operating System Support for Database Management》。论文的核心论断是：通用操作系统的内存管理决策对数据库负载是次优的。操作系统以"盲目"的全局策略（通常是LRU变体）管理内存，追求跨进程的公平性，却无法利用数据库独有的语义信息。 ...

1970年，Edgar Codd在IBM发表关系模型论文时，可能没有预见到Join操作会成为此后五十年数据库性能优化的核心战场。一个看似简单的"将两张表按共同键合并"的操作，在算法层面却隐藏着从$O(m \times n)$到$O(m + n)$的巨大差异——对于两张各有100万行的表，这意味着从万亿次比较降到百万次，性能差距可达六个数量级。 ...

数据库教科书告诉开发者一个简单的承诺：事务一旦提交，数据就是持久的。ACID中的"D"代表Durability——持久性。但生产环境中的实际情况远比教科书复杂：同样配置了主从复制、同样使用了SSD存储、同样收到了COMMIT成功的返回码，断电重启后，有些数据确实完好无损，有些却凭空消失了。 ...

用户在社交平台上发布了一条评论，刷新页面后评论消失了。再刷新一次，评论又出现了。用户困惑：我的评论到底保存成功了没有？ 这不是偶发的bug。在生产环境中，这类问题每天都在发生。根因往往指向同一个架构决策：读写分离。 ...

title: “为什么数据库索引选择B+树而不是Hash？从磁盘IO特性到范围查询的技术真相” date: “2026-03-07T05:05:02+08:00” description: “为什么数据库索引选择B+树而不是Hash？从磁盘IO特性到范围查询的技术真相” draft: false categories: [“数据库”, “系统设计”] tags: [“B+树”, “Hash索引”, “数据库索引”, “InnoDB”, “PostgreSQL”, “磁盘IO”, “范围查询”] 1972年，Rudolf Bayer和Edward McCreight在波音研究实验室工作时遇到了一个棘手问题：如何高效地组织存储在磁盘上的大量有序数据？他们在当年发表的论文"Organization and Maintenance of Large Ordered Indexes"中提出了B树（B-tree），这个数据结构在此后的半个世纪里统治了数据库索引设计。但有一个疑问始终困扰着许多开发者：Hash表在内存中拥有O(1)的查找效率，为什么数据库偏偏选择了看起来更慢的B+树？ ...