原文地址：Five Tips For a Healthier Postgres Database in the New Year
原文作者： Craig Kerstiens
这一年为了建造Crunchy Bridge十分忙碌，我们已经发布了许多新的产品。我没有总结所有的增长和令人兴奋的功能，而是想花时间尝试向那些跟随我们的人传递更多实用性的东西。在今年接连的用户入驻时，我注意到了要么为了改善数据库的运行状况、要么将自己从糟糕的一天中拯救出来，这里都有一些可以立即采取的优化关键措施。
设置语句超时
长时间运行的（通常是无意的）查询可能会对数据库造成严重破坏。它们可以阻止其他查询、复制或其他数据库进程。大多数应用程序都是为在几毫秒内运行的典型查询而设计的。您可能有长时间运行的报告查询，但最好将这些查询卸载到只读副本以进行报告和分析。要防止这些长时间运行的查询，您可以设置：statement_timeout
ALTER DATABASE mydatabase SET statement_timeout = '60s';
为了更好地衡量，您可能还希望将idle_in_transaction超时设置，这将取消不再执行工作的长时间运行的事务。
确保具有查询跟踪
了解数据库中发生的事情总是一个好主意。哪些查询速度较慢？哪些查询运行次数过多？输入存在的最有用的 Postgres 扩展：pg_stat_statements
Pg_stat_statements记录针对数据库运行的每个查询，对其进行参数化，然后记录有关它的各种指标。这使得回答上述问题变得容易。如果您还没有安装它，请立即运行：
CREATE EXTENSION pg_stat_statements;
一旦它到位，您可以查看我们关于它可以向您展示的所有见解的深入研究。
记录运行缓慢的查询
虽然pg_stat_statements对于查看频繁运行的查询或可能始终很慢的查询很有用，但有时您有极端异常值查询。通过pg_stat_statements您可以每隔几个月查看一次查询。同时，您的Postgres日志可能会馈送到您每天监视并发出警报的其他一些中央系统中。尽早捕获这些缓慢的异常值查询可能是一个很好的事情，您应该快速移动到只读副本以进行扩展或应该重写以提高效率。您可以使用log_min_duration_statement记录所有占用特定时间的慢查询。
对于许多SaaS应用程序，将您设置log_min_duration_statement为1秒左右：1s甚至低至100毫秒：100ms可能是重要的一个设置。
改进连接管理
如果您使用的是Rails，Django，Hibernate或任何其他框架/ ORM，那么您可能已经在数据库的应用程序设置中设置了连接池。该连接池可能会减少与数据库的新连接中的延迟，但也限制了数据库可用的性能。在Postgres 14之前的版本中，idle连接会消耗额外的开销，从而使连接浪费空间。此问题的解决方案不是替换应用内连接池，而是添加服务器端连接池，如 PgBouncer。使用PgBouncer，您可以毫无问题地扩展到数万个连接。您可以快速浏览一下您现有的数据库，看看PgBouncer是否有帮助
SELECT count(*),
state
FROM pg_stat_activity
GROUP BY 2;
如果您看到idle高于20，建议使用PgBouncer进行探索。添加 PgBouncer 通常无需花费任何精力即可获得更好的性能，而无需进行任何繁重的重构。为了方便起见，如果你在Crunchy Bridge上，它已经可供你使用。
查找您的goldilocks指数系列
应用程序中的索引似乎有一个共同的生命周期。首先，你开始时几乎没有，也许在主键上有几个。然后，您开始一个接一个地添加它们，直到您可以运行的大多数查询都有相当多的索引。有些东西很慢？向它抛出一个索引。你最终得到的是数据库整体吞吐量的问题，以及随着时间的推移，很多索引问题缠绕在一起。
我们有大量关于索引的文章和指南，不幸的是，没有“这是你要阅读和完成的一件事”。但是一些关键的问题可以查看以下内容：
