6

我遇到了这个 Postgres 问题，如果我使用参数而不是在查询字符串上硬编码其值，则执行相同的查询需要很长时间。列名是“media_type”，它是一个 VARCHAR(20)。我使用 Symfony2 和 Doctrine2 ORM 从 PHP 运行这些查询，并且有问题的表有大约 1.000.000 条记录。

我的查询有问题吗？会不会是 Postgres 配置问题？

1 - media_type 的硬编码值

duration: 5.365 ms  parse pdo_stmt_00000001: SELECT id,site_id FROM item where media_type = 'Collection' AND enabled = 'true' AND site_id = $1 AND user_id = $2 ORDER BY id DESC LIMIT $3 OFFSET $4
duration: 0.142 ms  bind pdo_stmt_00000001: SELECT id,site_id FROM item where media_type = 'Collection' AND enabled = 'true' AND site_id = $1 AND user_id = $2 ORDER BY id DESC LIMIT $3 OFFSET $4
parameters: $1 = '1', $2 = '1', $3 = '100', $4 = '0'
duration: 8.667 ms  execute pdo_stmt_00000001: SELECT id,site_id FROM item where media_type = 'Collection' AND enabled = 'true' AND site_id = $1 AND user_id = $2 ORDER BY id DESC LIMIT $3 OFFSET $4
parameters: $1 = '1', $2 = '1', $3 = '100', $4 = '0'

执行计划：

duration: 8.640 ms  plan:
    Query Text: SELECT id,site_id FROM item where media_type = 'Collection' AND enabled = 'true' AND site_id = $1 AND user_id = $2 ORDER BY id DESC LIMIT $3 OFFSET $4
    Limit  (cost=8.38..8.38 rows=1 width=12) (actual time=8.516..8.595 rows=24 loops=1)
      Buffers: shared hit=10 read=15
        ->  Sort  (cost=8.38..8.38 rows=1 width=12) (actual time=8.505..8.530 rows=24 loops=1)
            Sort Key: id
            Sort Method: quicksort  Memory: 26kB
            Buffers: shared hit=10 read=15
            ->  Index Scan using item_media_type_index on item  (cost=0.00..8.37 rows=1 width=12) (actual time=7.955..8.397 rows=24 loops=1)
                    Index Cond: ((media_type)::text = 'Collection'::text)
                    Filter: (enabled AND (site_id = $1) AND (user_id = $2))
                    Buffers: shared hit=8 read=15

2 - 使用 media_type 的参数（SLOWER）

duration: 5.557 ms  parse pdo_stmt_00000001: SELECT id,site_id FROM item where media_type = $1 AND enabled = 'true' AND site_id = $2 AND user_id = $3 ORDER BY id DESC LIMIT $4 OFFSET $5
duration: 1.322 ms  bind pdo_stmt_00000001: SELECT id,site_id FROM item where media_type = $1 AND enabled = 'true' AND site_id = $2 AND user_id = $3 ORDER BY id DESC LIMIT $4 OFFSET $5
parameters: $1 = 'Collection', $2 = '1', $3 = '1', $4 = '100', $5 = '0'
duration: 71564.998 ms  execute pdo_stmt_00000001: SELECT id,site_id FROM item where media_type = $1 AND enabled = 'true' AND site_id = $2 AND user_id = $3 ORDER BY id DESC LIMIT $4 OFFSET $5
parameters: $1 = 'Collection', $2 = '1', $3 = '1', $4 = '100', $5 = '0'

执行计划：

duration: 71564.922 ms  plan:
    Query Text: SELECT id,site_id FROM item where media_type = $1 AND enabled = 'true' AND site_id = $2 AND user_id = $3 ORDER BY id DESC LIMIT $4 OFFSET $5
    Limit  (cost=90663.16..181326.31 rows=17184 width=12) (actual time=3.667..71564.864 rows=24 loops=1)
      Buffers: shared hit=183786 read=96585
        ->  Index Scan Backward using item_pkey on item  (cost=0.00..906610.46 rows=171836 width=12) (actual time=3.655..71564.798 rows=24 loops=1)
               Filter: (enabled AND ((media_type)::text = $1) AND (site_id = $2) AND (user_id = $3))
               Buffers: shared hit=183786 read=96585

提前致谢。

4

3 回答 3

9

这是 PostgreSQL 中一个长期存在的缺陷，从历史上看，它需要一些有趣的规划器调整来解决。它在 PostgreSQL 9.2（现在是测试版）中得到了修复，不过像往常一样感谢 Tom Lane。

E.1.3.1.3。优化器

提高计划者选择参数化计划的能力 (Tom Lane)

准备好的语句现在被解析、分析和重写，但不一定是计划好的。当使用参数执行准备好的计划时，计划器可能会为每个常量重新计划它，或者如果其成本接近于特定于常量的计划的成本，它可能会执行通用计划。

请参阅9.2 beta 发行说明和我在 lwn.net 上写的关于此的快速说明。在邮件列表中有很多关于处理准备好的/参数化的语句运行速度比正常语句慢的信息。

于 2012-05-31T06:46:26.727 回答
2

当我绑定到一个 SMALLINT 字段并传入一个 Postgres 隐式从 INTEGER 转换为 SMALLINT 的值时，我遇到了一个非常类似的问题。我通过明确演员来修复它。由于 media_type 是 VARCHAR(20) 类型，Postgres 正在从 TEXT 类型进行隐式转换。尝试这个：

where media_type = $1::VARCHAR(20)

于 2012-05-30T23:56:16.353 回答
1

在您的静态、更快的查询中，正在使用 item_media_type_index。在您绑定的较慢查询中，未使用 item_media_type_index。

“item”表中“media_type”列的选择性是什么？如果你做了：

SELECT media_type, COUNT(*)
  FROM item
  GROUP BY media_type
  ORDER BY 2 desc

media_types 是否均匀平衡，或者与其他媒体类型相比，'Collection' media_types 是否相对较少？如果“Collection”项目相对较少，那么我会冒险猜测：使用静态查询，解析器知道您正在查询“Collection”，并且可以确定“Collection”的计数较低并且索引可能值得使用。但是在绑定变量的情况下，解析器不知道您使用的是哪个 media_type。其他一些 media_type 值可能占表中记录的很大比例（例如 20%）。在这种情况下，进行扫描甚至比使用索引还要麻烦。解析器需要做出决定，并且恰好决定不使用索引（对于您的情况是错误的，但对于其他 media_type 可能是正确的）。

在这种情况下，如果您知道选择性属性非常偏斜，则答案是硬编码，使用动态 sql 强制延迟解析，或者如果您认为正确，则强制使用索引。

于 2012-05-31T00:29:41.870 回答