PostgreSQL是一个支持几乎所有SQL构造的开源对象关系DBMS。 在本教程中，我们将尝试提供优化查询的工具。 当您需要提高数据库的性能时，请考虑如何使用受影响的表。 有时，表主要用于插入，在其他情况下仅用于选择数据，但通常您需要提前知道偏差。

当PostgreSQL收到查询时，首先要解析它，并且可能会重写它，通常在考虑性能时这不是问题。 接下来的事情是生成一个执行计划，实际上它比这更多，但是让事情变得简单。

要了解PostgreSQL如何生成计划，我们使用EXPLAIN查询，我们也使用ANALYZE。 以下是Postgresql的描述。

我们不建议在生产服务器上执行EXPLAIN ANALYZE查询。 为此，我们需要使用完全相同的数据库模式来设置一个测试postgres。 使用此模式，我们建议使用受影响的表的随机行，并检查每列的数据分布。 拥有每个列值的随机分布将允许我们用更多的实际数据填充测试表。

现在我们有测试环境，我们需要配置PostgreSQL来记录慢查询。 要执行此操作搜索log_min_duration_statement键并将其设置为正值，如300毫秒。

现在开始使用你的应用程序来知道哪些查询速度很慢。 我们将在后续步骤中分析这些查询。

这里有一个非常慢的查询示例：

如果您使用postgres默认配置，那么在开始出现性能问题时，您应该查看该文件，因为配置是针对平均用例。 如果你有一个非常大的服务器机会大，你需要更改你的配置。。

在测试环境中这样做是没有用的，因为Vacuum会优化内部数据库结构！Vacuum检查你的生产环境。

Vacuum是Postgres查询删除删除或废弃的元组。

首先检查lastime，Vacuum进行查询：

我的情况时，列last_vacuum显示它是在几个月前完成的。 我的用例是读取，因为当表已经被填充，没有更多的插入或更新完成。 以防万一，我做了Vacuum：

您可以配置自动Vacuum，但请记住，在执行VACUUM查询时，Vacuum过程可能会使数据库变慢。 在我们的示例中，我们使用10000行作为阈值，这意味着在10000次插入，更新或删除后，该表是自动Vacuum。

我们建议您使用一个积极的自动Vacuum设置来做VACUUM FULL。

我们的表格模式如下：

在我们的日志中使用慢查询，我们将使用explain analysis来诊断可能出现的问题。 我们的表格使用相同的生产环境数据分布填充了100 Millon行。

以下是说明分析结果：

对表执行计数

正如我们可以看到，postgres正在使用我们期望的multi_index。 但执行时间是完全不可接受的。 由于我们有一个索引扫描，我们还执行一个VACUUM FULL。 由于我们在column5和column3上使用相等性，所以我们尝试在这些列中添加部分索引。

特别是column5将我们的表分成两部分，但column3并非如此。 我们通常执行其他值的查询，如2和1。

CREATE INDEX column3_and_column5_idx ON example_table ON example_table where column5=0 and column3=1 or column3=2 or column3=5; CREATE INDEX column3_and_column5_idx ON example_table ON example_table where column5=1 and column3=1 or column3=2 or column3=5;

现在这是输出的解释