PostgreSQL 缓存命中率低？可以这么做.doc

Rhein

14页

17次

2025-04-16

免费下载

PostgreSQL

缓存命中率低？可以这么做

在



中，在分析数据库性能时，经常需要处理缓存命

中率低的问题。

介绍

磁盘活动比从内存读取数据慢得多。根据当今设备的性能规格，

从内存读取大约需要



纳秒，而从物理驱动器读取需要



微秒

（对于



）到



毫秒（对于



）。这比访问随机内存存储

器慢



倍。从



缓存读取甚至更快，可能只需要



个



周期，不到



纳秒。因此，从物理驱动器进行每次读取都会对

性能造成巨大影响，应避免使用。在本教程中，我们将了解如何诊

断分析，我们无法利用缓存数据，并需要从物理驱动器读取数据的

场景。我们将了解为什么它很重要，要寻找什么，以及要使用哪些

工具和扩展。

数据库如何读取数据

数据库在直接从硬盘驱动器读取数据时，可以很好地意识到性能

问题。因此，它们结合了许多复杂的技术来提高性能，并尽可能缓

存数据。让我们看看数据库如何访问数据，以及接下来会发生什么。

读取数据的各种方式

最基本的方法是，当数据库需要读取未配置聚集索引的表时，这

样的表有时称为堆表。引擎只需逐一扫描每一行，相应地过滤它们，

然后再做进一步处理。

数据存储在所谓的页面中。数据库引擎将数据分块为较小的部分，

然后将这些部分存储在驱动器上。每个部分称为一个页面，通常为



大小（尽管这是可配置的）。遗憾的是，由于数据库通常不允

许一行跨越多个页面，因此浪费了一些空间。这种现象称为 “碎片

化”，会导致一些空间浪费。扫描整个表时，数据库引擎必须读取的

数据量，会超过数据的实际大小，这使得整个过程更加缓慢。

当我们考虑数据修改时，事情会变得更加复杂。当我们删除一行

时，数据库引擎必须将其从页面中删除，而这种情况实际上很少发

生。更常见的是，数据库只是将行标记为已删除（“已死”），然后在

扫描表时忽略它。但是，数据库仍然需要读取死行，当我们有很多

死元组时，这可能会进一步降低性能。

这意味着随着时间的推移，我们的数据库会变慢。为了辅助改善

这一点，我们需要对表进行碎片整理（有时称为 “



）。此

过程使数据库读取所有数据，并以更有条理的方式将其写入一侧，

以删除死元组并恢复一些浪费的空间。

由于所有这些内部细节，数据库引擎有很多方法可以加快速度。

第一种方法是用多个读取器并行扫描表。如果我们可以一次执行多

个读取，这会使事情变得更快，当我们将驱动器放在



磁盘阵

列中时，这通常是可能的。然而，真正改变游戏规则的是索引。

聚集索引是一种将数据保存在



树（广义二叉树）中的结构。所

有行都根据一些属性（如行号）进行排序，因此我们可以更快地搜

索行。最重要的是，我们不需要读取所有数据来根据标识符查找行。

这样我们就可以避免昂贵的读取，并轻松 “跳转” 到所需的记录。请

务必了解，当我们在表上配置聚集索引时，索引将成为表。如果可

能，所有数据都保存在索引节点中。这在一定程度上降低了读取性

能（因为我们需要完整地读取大行），但仍然允许我们利用索引和

二分查找。如果我们不想将整个数据存储在索引节点中，我们可以

构建额外的索引，这些索引将仅包含一些列和指向实际行的指针，

然后数据库将首先从辅助索引中读取，然后转到主表以获取行的内

容。

还有更多技术可以提高性能（如位图扫描、列存储和其他类型的

索引），但是，它们都专注于一件简单的事情



尽可能少地读取。

读取后会发生什么

从驱动器读取数据后，数据库引擎可能希望将其保存在内存中，

以加快接下来的操作的速度。因此，每个页面都可以存储在缓存中。

根据数据库类型，可能有许多级别的缓存和不同的缓存策略。我们

可以直观地将这些视为内存的一部分，用于保留从驱动器读取的内

容，即使在我们完全处理了数据之后也是如此。

数据库缓存只是一个级别的缓存。另一个级别是操作系统的缓存，

还有一个级别是



缓存。即使我们在数据库缓存中找不到数据，

它仍然可能在系统缓存中（因此文件系统不需要从驱动器中读取），

或者在



缓存中。当数据库想要读取一个内存页时，缓存的实际

工作方式如下：

首先，数据库检查自己的缓存。如果数据在那里，那么数据库•

想要读取它

of 14

免费下载

墨力计划

相关文档

评论