Snowflake Postgres 见解¶

缓存命中¶

Postgres 通常会尝试将您最常访问的数据保留在其共享缓冲区缓存中。缓存命中率衡量的是缓冲区缓存能够处理的内容请求数与其接收的总请求数的比值。缓存命中是指已成功处理的请求，未命中是指未成功处理的请求。未命中将绕过缓存，通过文件系统来满足请求。

因此，如果有 100 次缓存命中和 2 次未命中，则缓存命中率为 100/102，约等于 98%。

为了保证 Postgres 的正常运行和性能，您通常需要将 Postgres 缓存命中率保持在 99% 左右。

如果您发现缓存命中率低于该水平，则可能需要考虑迁移到内存更大的实例。

索引命中¶

向数据库添加索引对于查询和应用程序性能至关重要。索引在大型表中尤其具有价值。

索引命中率是以成功利用索引的查询或查询执行总数与已执行查询总数的比率或百分比来衡量的。较高的索引命中率表明索引利用率更高，整体查询性能更好。

通常，对于超过 10,000 行的表，您需要追求 99% 以上的命中率。如果您看到一个超过 10,000 行的表没有或只有较低的索引使用率，那么这就是开始添加索引的最佳切入点。

未使用的索引¶

PostgreSQL 中未使用的索引是指在表上创建但未被积极使用的索引。这些索引会占用磁盘空间，需要维护，并且会对性能产生负面影响。

以下是您应该关注 Postgres 中未使用索引的几个原因：

• 存储和磁盘空间：未使用的索引占用了本可以更好地用于其他用途的磁盘空间。这会导致存储成本增加，并减少其他数据库对象的可用空间。

• 性能影响：在数据修改操作（如插入、更新和删除）期间，索引会产生额外开销。当存在大量未使用索引时，这些操作需要更长时间，因为除了表之外，数据库还必须更新多个索引。

• 查询执行速度变慢：Postgres 的查询优化器在为查询生成执行计划时会考虑所有可用索引。如果存在未使用的索引，优化器可能会花费额外的时间来评估这些索引，从而导致生成次优的查询计划并降低查询执行速度。

• 维护开销：维护索引需要消耗资源，包括 CPU 和磁盘 I/O。如果存在大量未使用的索引，这些资源就会被浪费在不必要的索引维护任务上。

膨胀¶

膨胀是指数据库中死行和未使用行的累积，导致磁盘空间消耗和性能下降。它主要影响事务工作负载较高的数据库。Postgres 的 MVCC 系统会创建一行的多个版本来处理并发事务。更新或删除行时，系统会创建一个新版本，而旧版本会被标记为失效。为了保持事务完整性并确保并发操作期间的数据一致性，这些死行不会立即从表中移除。

为了回收死行占用的磁盘空间，Postgres 会定期执行清理操作。此过程会识别并消除表中的死行，从而释放磁盘空间以供重复使用。当高频事务在两次清理进程之间产生大量死行时，就会发生膨胀。

我们提供膨胀百分比，以显示死行占用的空间量与表或索引总大小的比值。显示的膨胀是估计值或近似值。如果您需要有关表中膨胀的更多详细数据，可以使用扩展插件 pgstattuple (https://www.postgresql.org/docs/current/pgstattuple.html)，但这可能是一项资源密集型操作。

低膨胀：膨胀低于 50% 通常被认为是可以接受的，通常不需要采取行动。仍建议监控膨胀的进一步增长情况，并检查清理的配置和设置。

高膨胀：膨胀超过 50% 表明膨胀程度较高，可能会开始严重影响性能和磁盘空间利用率。如果您注意到查询变慢或出现性能问题，可能需要考虑采取行动，例如执行手动清理操作或更改清理设置。

对于小于 1GB 或膨胀百分比小于 10% 的表，我们不显示膨胀百分比。

异常查询¶

这些是执行时间占比最高的查询。这可能包括非常慢但频率较低的查询，以及稍微变慢但极其频繁的查询。执行时间占比最高的查询是在应用程序级别进行数据库查询调优或编制索引的最佳起点。

长时间运行查询¶

PostgreSQL 中的长时间运行查询可能会对您的数据库和应用程序产生多方面的负面影响。以下是为什么长时间运行查询通常被认为是不理想的一些原因：

• 性能影响：长时间运行查询会长时间占用数据库资源，包括 CPU、内存和磁盘 I/O。

• 争用增加：长时间运行查询可能会导致对共享资源的争用增加，例如锁以及对数据库对象的并发访问。

• 吞吐量降低：当一个查询需要很长时间才能完成时，它会限制在给定时间范围内可以执行的查询总数。

• 户体验差：如果您的应用程序依赖于及时的查询执行，长时间运行查询可能会对用户体验产生负面影响。用户可能会遇到延迟或无响应，从而导致对您的应用程序感到沮丧和不满。

• 资源耗尽：长时间运行查询可能会消耗过多的内存，导致内存使用量增加并可能引发内存不足错误。它们还可能在磁盘上生成大型临时文件，可能导致磁盘空间问题。

清理¶

见解面板还包含清理统计信息。您可以查看表名、上次手动清理和上次自动清理的时间。您还可以深入了解存在多少死行、清理操作上次清理死行的时间等信息。

清理统计信息包括：

• 表名称

• 上次清理：上次运行手动清理操作的时间

• 上次自动清理：上次运行自动清理的时间

• 行数：表的总行数

• 死行计数：表中当前未清理/死行的数量

• 比例因子：自动清理设置中设置的当前比例因子

• 阈值：根据比例因子计算出的需要进行清理操作的总行数

• Should vacuum: if you should manually vacuum the table

表大小¶

有关 Postgres 表大小的详细信息，可在实例见解中的“表大小”下找到。其中显示了如下表信息：

• 表名

• 近似行数

• 表总大小

• 表上的索引大小

• TOAST 表中的表字节数

• 原始行表大小

连接¶

连接见解显示了数据库实例中当前所有的活动连接和空闲连接。活动连接处于当前已连接到数据库、正在执行查询或等待执行查询的会话中。

空闲连接很常见，其本身并不是问题，但根据您的工作负载和配置，它们可能会变成一个问题。空闲连接会消耗内存，因此大量的空闲连接可能会导致内存使用量过高。高空闲连接通常表明数据库会从连接池中受益。

每个运行中的会话都有一个 pid，即进程 ID，这是分配给每个活动后端连接的唯一标识符。

要取消连接、查询或进程但保持会话开启，请使用此语句：

SELECT pg_cancel_backend(<pid>);

一个将关闭连接并回滚所有事务的更强制的操作是：

SELECT pg_terminate_backend(<pid>);