Postgresql 加快查询速度

因此，正如我前面提到的，我不处理通常需要帮助增强此查询的原始SQL。目前，大约需要3秒钟。我想知道他们是否有办法让它变得更好。我删除了一些选择以使查询更小

select row_number() over ()                      as id,
       scope.id                                  as sow_id,
       scope.*,
       task.*,
       po.entity_id                              as group_name
from t_scope_of_work as scope,
     (select * from audittaskimpl) as task
         Left join peopleassignments_potowners po ON task.taskid = po.task_id and po.entity_id like '%/%'
Where task.processinstanceid IN
      (select distinct processinstanceid from taskvariableimpl where value = scope.sownumber)
order by task.processinstanceid desc, task.createdon desc;

---

您的查询归结为：

select row_number() over ()                      as id,
       scope.id                                  as sow_id,
       scope.*,
       task.*,
       po.entity_id                              as group_name
from t_scope_of_work as scope
join audittaskimpl as task
  on task.processinstanceid IN  (select distinct tvi.processinstanceid 
                                   from taskvariableimpl tvi
                                  where tvi.value = scope.sownumber)
Left outer join peopleassignments_potowners po 
             ON po.task_id = task.taskid 
            and po.entity_id like '%/%'

order by task.processinstanceid desc, task.createdon desc;

如果没有解释，就很难知道这个查询中的瓶颈在哪里。例如，您可能缺少一些索引，可能是因为数据太多，无法如此快速地获取

也就是说，我怀疑你是否需要那种与众不同的东西；事实上，可能值得尝试一个EXISTS结构，仅仅是为了看看它能提供什么。 大概是这样的：

 select row_number() over ()                      as id,
       scope.id                                  as sow_id,
       scope.*,
       task.*,
       po.entity_id                              as group_name
from t_scope_of_work as scope
join audittaskimpl as task
  on exists ( select * 
                from taskvariableimpl tvi
               where tvi.value             = scope.sownumber
                 and tvi.processinstanceid = task.processinstanceid )
Left outer join peopleassignments_potowners po 
             ON po.task_id = task.taskid 
            and po.entity_id like '%/%'

order by task.processinstanceid desc, task.createdon desc;

---

警告：购买前请先试用！这可能比您最初的查询更糟糕，我以前从未在EXISTS上执行过联接[…]；同样，在没有正确了解表、卷、索引、数据布局的情况下读取：连接中是否有许多“命中”项，或者只有少数记录？等等。。。我们在这里的工作几乎是盲目的。

您好，首先我要对它进行解释分析，以便您对数据库实际使用它做了什么有一个合理的估计。您是否通过替换WHERE。。。在使用内部联接的情况下？其他人可能也能提供帮助，但不会有什么不同，但是：从audittaskimpl as任务中选择*可以简化为audittaskimpl as任务。请不要在WHERE子句和explicit JOIN运算符中混合使用旧的、古老的和脆弱的隐式联接。对所有联接使用显式联接简化您的问题并添加使用解释分析、缓冲区、格式化文本生成的联接，而不仅仅是简单的解释，并确保保留计划的缩进。粘贴文本，然后将“``放在计划前一行，计划后一行。还请包括所有索引的完整CREATEINDEX语句。这非常令人惊讶，不确定您是如何做到的，但看起来它从2-3秒到300毫秒。

 select row_number() over ()                      as id,
       scope.id                                  as sow_id,
       scope.*,
       task.*,
       po.entity_id                              as group_name
from t_scope_of_work as scope
join audittaskimpl as task
  on exists ( select * 
                from taskvariableimpl tvi
               where tvi.value             = scope.sownumber
                 and tvi.processinstanceid = task.processinstanceid )
Left outer join peopleassignments_potowners po 
             ON po.task_id = task.taskid 
            and po.entity_id like '%/%'

order by task.processinstanceid desc, task.createdon desc;