优化 Postgres 查询

Posted 2023-04-14

【中文标题】优化 Postgres 查询

【英文标题】：Optimize Postgres Query

【发布时间】：2013-09-27 03:52:16

【问题描述】：

我注意到我的代码中有以下查询，并想检查这是否可以优化。

UPDATE table as T1 SET C1=? 
  FROM 
    (SELECT C2, C3, C4 
        FROM table 
        WHERE C1=? and current_timestamp >= C5 
        ORDER BY C5 limit ? FOR UPDATE
    ) AS T2 
WHERE T1.C2 = T2.C2 AND T1.C3 = T2.C3 AND T1.C4 = T2.C4
RETURNING *;

C2、C3 上的索引

在 C5 上分区

表：

C1、C2、C3 - varchar C4、C5 - 时间戳

【问题讨论】：

不可能只用一个非常神秘的查询来回答。使用解释分析来找出 postgresql 花费时间的地方。如果您在解释分析的输出方面需要帮助，请将其插入您的问题中。

无法保证子查询为每个目标行准确返回一（或零）行。请先修复您的逻辑，然后再尝试优化您的性能。 （order by .. limit 1 是一种将子查询限制为一行的糟糕方法，如果这是您的意图）

【参考方案1】：

过早的优化是数据库中万恶之源。设计时要考虑到理智，然后在遇到问题时向我们展示。我不会回答这个问题，而是解释为什么无法回答。

SQL 是一种声明性语言，您可以在其中向数据库系统提供类似于数学公式的东西，它会计算出如何以最佳方式运行它。嗯，从技术上讲，查询是一个数学公式，但数学反映了 SQL，而 SQL 近似于另一个数学领域，称为关系代数。

实际的优化过程很大程度上取决于读写模式，以及规划者知识的局限性。在您遇到实际瓶颈之前，没有办法评估一个查询相对于另一个查询的相对性能，除非您执行示例中不存在的某些事情（NOT EXISTS 往往很昂贵，而将其写成外连接和过滤内连接的情况，而不是作为反连接。大概这将在未来得到解决）。即使在这种情况下，也有很多情况下反连接不会产生太大影响，而且性能提升可能不值得担心。

因此，关键是您需要等到出现实际问题后再优化查询。然而，优化存储是非常不同的。