Sql POSTGRES-子查询返回结果的速度非常慢

Sql POSTGRES-子查询返回结果的速度非常慢,sql,postgresql,subquery,Sql,Postgresql,Subquery,我有一个相当简单的查询,但它包含一个子查询。 我想获取资源\u id的列表,它们按DESC的顺序通过过滤器顺序 更多信息 基本上,我们需要找到通过下面查询中提到的过滤器的资源id的列表 SELECT rs.resource_id FROM resource rs WHERE ( SELECT rc.resource_id FROM risk_child rc WHERE rc.resource_id = rs.resource_id AND rc.clou

我有一个相当简单的查询,但它包含一个子查询。 我想获取
资源\u id
的列表,它们按DESC的顺序通过过滤器顺序

更多信息 基本上,我们需要找到通过下面查询中提到的过滤器的
资源id的列表

   SELECT rs.resource_id
FROM resource rs
WHERE (
    SELECT rc.resource_id
    FROM risk_child rc
    WHERE rc.resource_id = rs.resource_id 
    AND rc.cloudaccount_id = rs.cloud_account_id
    AND rs.reg_id= any(array[236]) 
    AND rc.risk_level= any(array['high','low'])
    AND rc.status = any(array['fail'])
    AND rc.cloudaccount_id= any (array['4ZiCmwslbjhmRtHAOjLG'])
    ORDER BY rc.id DESC
    LIMIT 1
) = rs.resource_id
然后,这些资源将被传递到另一个查询中,如下所述:

SELECT
  DISTINCT ON (rc.resource_id, rc.rule_id, s.id) MAX(rc.creationtime) as creationtime,
  rc.resource_id,
  rl.rule_tag,
  s.service,
  r.region,
  rc.status,
  rs.vpc_id,
  rc.cloudaccount_id,
  rc.organization_id,
  rs.owner_id,
  rc.description,
  f.function_name,
  g.group_name,
  rc.risk_level,
  rc.id,
  rc.user_id,
  rc.pro_id,
  c.category_name,
  rc.raw as rawResponse,
  rs.res_ca_id,
  rs.resource_name
FROM
  risk_child rc,
  resource rs,
  rule rl,
  service s,
  region r,
  function f,
  g_by g,
  category c
WHERE
  rc.resource_id = rs.resource_id
  AND rl.id = rc.rule_id
  AND s.id = rs.ser_id
  AND rs.reg_id = r.id
  AND f.id = rc.function_id
  AND c.id = rc.category_id
  AND g.id = rc.group_id
  AND rc.cloudaccount_id like any (array $ { modifiedCloudAccounts })
  AND rc.organization_id = $ { orgId }
  AND rc.rule_id > 0
  AND rc.cloudaccount_id = rs.cloud_account_id
  AND rs.resource_id like any (array $ { getResources }) $ { risk }
GROUP BY
  rc.rule_id,
  rc.creationtime,
  rc.creationtime,
  rc.resource_id,
  rl.rule_tag,
  rl.id,
  s.service,
  r.region,
  rc.status,
  rs.vpc_id,
  rc.cloudaccount_id,
  rc.organization_id,
  rs.owner_id,
  rc.description,
  f.function_name,
  g.group_name,
  rc.risk_level,
  rc.id,
  rc.user_id,
  rc.pro_id,
  c.category_name,
  rc.raw,
  s.id,
  rs.res_ca_id
ORDER BY
  rc.resource_id,
  rc.rule_id ASC;
问题 现在,第一个查询返回结果的速度非常慢,即使在索引之后,结果也只需5-6秒。因此请记住,第一个查询需要运行两次

  • 一个获取行总数(用于分页)
  • 第二次获取资源\u ID
  • 我主要在我的应用程序中使用非SQL,所以我对SQL查询相当陌生。任何帮助都将不胜感激。
    谢谢

    所以我的案子终于成功了:

        SELECT rs.resource_id
    FROM resource rs
    WHERE EXISTS (SELECT *
                  FROM risk_child rc
                  WHERE rc.resource_id = rs.resource_id 
                    AND rc.cloudaccount_id = rs.cloud_account_id
                    AND rs.reg_id= any(array[236]) 
                    AND rc.risk_level= any(array['high','low'])
                    AND rc.status = any(array['fail'])
                    AND rc.cloudaccount_id= any (array['4ZiCmwslbjhmRtHAOjLG'])
                 )
    
    基本上,正如我在文章中所解释的,我对SQL是相当陌生的,我没有在表中添加适当的索引,因此我必须添加以下索引以加快查询速度


    resource(resource\u id,cloud\u account\u id)
    risk\u child(resource\u id,cloudaccount\u id)
    这帮助我进一步提高了绩效

    请回答您的问题,并使用
    解释(分析、缓冲区、格式文本)
    (不仅仅是“简单”的解释)添加生成的内容,并确保防止缩进计划。粘贴文本,然后将
    `
    放在计划前一行和计划后一行。还请包括所有索引的完整
    create index
    语句。
    distinct on()
    groupby
    看起来很奇怪。与性能无关,但您应该真正避免那些古老而脆弱的隐式连接,并使用“现代”(近30年)显式连接运算符。我知道第二个查询很糟糕,因为我解释过我的背景不是SQL。所以我不擅长,但是第二个查询返回结果的速度相当快,比如大约1-2秒,这在我们的场景中非常有效,问题是第一个。这两个查询之间的关系是什么?你需要合并它们吗?我认为第二个查询可以简化为这样:实际上,第一个查询为我们提供了一个
    resource\u id
    s列表,然后这些列表被传递到第二个查询,它们没有连接,而是一个接一个地运行。主要结果来自第二个查询。既然你自己解决了这个问题,那么你最好删除这个问题。我不应该把它留在这里,这样其他人可以从中获得帮助吗?