【问题标题】:PostgreSQL query efficiencyPostgreSQL查询效率
【发布时间】:2012-11-01 16:37:47
【问题描述】:

我正在使用 PostgreSQL(我是数据库领域的新手),我想知道您对我在使用的代码中发现的此类查询的效率的看法。这些查询有很多 JOIN,其中一个(粗体)按请求有很多行。这迫使我们使用 GROUP BY request.id 以按请求获取行和包含所有这些行数据的字段(粗体)。

我认为这种查询必须花费大量时间来寻找所有这些最大值,但我想不出另一种方法来做到这一点。关于它的效率以及如何改进它的任何想法?

SELECT
  request.id AS id,
  max(request_type.name) AS request_type,
  to_char(max(request.timestamp),'DD/mm/YYYY HH24:mi') AS timestamp,
  to_char(max(request.timestamp),'YYYY-mm-DD') AS timestamp_filtering,
  max(state.name) AS request_state,
  max(users.name || ' ' || COALESCE(users.surname,'')) AS create_user,
  max(request.id_create_user) AS id_create_user,
  max(enterprise.name) AS enterprise,
  max(cause_issue.name) AS cause,
  max(request_movements.id_request_state) AS id_state,
  array_to_string(array_agg(DISTINCT act_code.name || '/' || req_res.act_code), ', ') AS act_code, /* here */
  max(revised.code) AS state_revised, 
  max(request_shipment.warehouse) AS warehouse,
  max(req_res.id_warehouse) AS id_warehouse
FROM
  request
  LEFT JOIN users
    ON users.id=request.id_create_user
  LEFT JOIN enterprise
    ON users.id_enterprise=enterprise.id
  LEFT JOIN request_movements
    ON request_movements.id=request.id_request_movement
  LEFT JOIN request_versions
    ON request_versions.id = request_movements.id_version
  LEFT JOIN state
    ON request_movements.id_request_state=state.id
  INNER JOIN request_type
    ON request.id_request_type=request_type.id
  LEFT JOIN cause_issue
    ON request.id_cause_issue=cause_issue.id
  LEFT JOIN request_reserve req_res
    ON req_res.id_request = request.id /* here */
  LEFT JOIN act_code
    ON req_res.id_act_code=act_code.id
  LEFT JOIN request_shipment
    ON (request_shipment.id_request=request.id)
  LEFT JOIN warehouse_enterprise
    ON (warehouse_enterprise.id = request_shipment.id_warehouse_enterprise)
  LEFT JOIN revised
    ON (revised.id = request_shipment.id_revised)
WHERE
  request.id_request_type = "any_type"  
GROUP BY
  request.id

解释返回this

【问题讨论】:

  • 你是否已经在这个查询上运行了EXPLAIN
  • 是的,但正如我所说,我是这方面的新手,我还没有阅读足够的内容来利用这种分析
  • 你可能想添加解释的输出然后,它可以帮助人们分析你的情况。
  • 发布执行计划最好的方式是上传到explain.depesz.com
  • 这是很多左连接和聚合o_O

标签: sql postgresql aggregate-functions postgresql-8.4 postgresql-performance


【解决方案1】:

您可以通过将 request_reserveact_code beforeJOIN 中的值聚合到大连接来大大简化此查询。这避免了对所有其他列的聚合函数的需要,并且对于更多的行通常应该更快。

SELECT r.id
      ,rt.name AS request_type
      ,to_char(r.timestamp, 'DD/mm/YYYY HH24:mi') AS timestamp
      ,to_char(r.timestamp, 'YYYY-mm-DD') AS timestamp_filtering
      ,s.name AS request_state
      ,u.name || COALESCE(' ' || u.surname, '') AS create_user
      ,r.id_create_user
      ,e.name AS enterprise
      ,c.name AS cause
      ,rm.id_request_state AS id_state
      ,rr.act_code
      ,rd.code AS state_revised
      ,rs.warehouse
      ,rr.id_warehouse
FROM      request              r
LEFT JOIN users                u  ON u.id = r.id_create_user
LEFT JOIN enterprise           e  ON e.id = u.id_enterprise
LEFT JOIN request_movements    rm ON rm.id = r.id_request_movement
LEFT JOIN request_versions     rv ON rv.id = rm.id_version
LEFT JOIN state                s  ON s.id = rm.id_request_state
     JOIN request_type         rt ON rt.id = r.id_request_type
LEFT JOIN cause_issue          c  ON c.id = r.id_cause_issue
LEFT JOIN request_shipment     rs ON rs.id_request = r.id
LEFT JOIN warehouse_enterprise w  ON w.id = rs.id_warehouse_enterprise
LEFT JOIN revised              rd ON rd.id = rs.id_revised
LEFT JOIN (
   SELECT rr.id_request, rr.id_warehouse
         ,array_to_string(array_agg(
             DISTINCT a.name || '/' || rr.act_code), ', ') AS act_code
   FROM   request_reserve rr
   LEFT   JOIN act_code   a ON r.id_act_code = a.id
   GROUP  BY rr.id_request, rr.id_warehouse
   )  rr ON rr.id_request = r.id
WHERE  r.id_request_type = "any_type";  -- use single quotes for values!

对于大型查询,您必须拥有一种人眼可以轻松解析的格式。因此,我在改进查询之前重新格式化。 我使用表别名来尽可能避免笨拙的标识符。

create_user 的小改进:没有尾随空格。如果名称的任何一部分可以是NULL,我建议这样做以避免悬空:

COALESCE(u.name || ' ' || u.surname, u.name, u.surname)

在 PostgreSQL 9.1 或更高版本中,您可以使用concat_ws()

【讨论】:

  • 哦!惊人的!非常感谢欧文!明天我会试一试,我会反馈结果给大家观看。
  • 我对@9​​87654330@ 有点怀疑,看起来每个request 可能有n 行。但是你说不是这样的..
  • 我是对的,相信我 ;) 就像你在诊断时一样。优秀作品!!查询现在花费的时间是之前花费的一半以上。非常感谢您的宝贵时间。很有用!
猜你喜欢
  • 2019-07-27
  • 1970-01-01
  • 2012-02-09
  • 1970-01-01
  • 1970-01-01
  • 2014-11-09
  • 2012-10-16
  • 2011-05-07
相关资源
最近更新 更多