PostgreSQL 查询耗时过长

Question

我有几亿行的数据库。我正在运行以下查询：

select * from "Payments" as p
inner join "PaymentOrders" as po
on po."Id" = p."PaymentOrderId"
inner join "Users" as u
On u."Id" = po."UserId"
INNER JOIN "Roles" as r
on u."RoleId" = r."Id"
Where r."Name" = 'Moses'
LIMIT 1000

当 where 子句在数据库中找到匹配项时，我会在几毫秒内得到结果，但如果我修改查询并在 where 子句中指定不存在的 r."Name"，则需要花费太多时间才能完成。我猜 PostgreSQL 正在对Payments 表（包含最多行）进行顺序扫描，逐一比较每一行。

postgresql 还不够聪明，无法先检查Roles 表是否包含Name 'Moses' 的任何行吗？

Roles 表仅包含 15 行，而 Payments 表包含约 3.5 亿行。

我正在运行 PostgreSQL 9.2.1。

顺便说一句，对相同架构/数据的相同查询在 MS SQL Server 上完成需要 0.024 毫秒。

我会在几个小时内更新问题并发布 EXPLAIN ANALYZE 数据。

---

这里解释一下分析结果：http://explain.depesz.com/s/7e7

---

这是服务器配置：

version PostgreSQL 9.2.1, compiled by Visual C++ build 1600, 64-bit
client_encoding UNICODE
effective_cache_size    4500MB
fsync   on
lc_collate  English_United States.1252
lc_ctype    English_United States.1252
listen_addresses    *
log_destination stderr
log_line_prefix %t 
logging_collector   on
max_connections 100
max_stack_depth 2MB
port    5432
search_path dbo, "$user", public
server_encoding UTF8
shared_buffers  1500MB
TimeZone    Asia/Tbilisi
wal_buffers 16MB
work_mem    10MB

我在 i5 cpu（4 核，3.3 GHz）、8 GB RAM 和 Crucial m4 SSD 128GB 上运行 postgresql

---

更新 这看起来像查询计划器中的错误。在 Erwin Brandstetter 的推荐下，我将其报告给了Postgresql bugs mailing list。

Answer 1

正如 PostgreSQL 社区性能列表上的线程多次建议的那样，您可以通过使用 CTE 强制优化障碍来解决此问题，如下所示：

WITH x AS
(
SELECT *
  FROM "Payments" AS p
  JOIN "PaymentOrders" AS po ON po."Id" = p."PaymentOrderId"
  JOIN "Users" as u ON u."Id" = po."UserId"
  JOIN "Roles" as r ON u."RoleId" = r."Id"
  WHERE r."Name" = 'Moses'
)
SELECT * FROM x
  LIMIT 1000;

如果您为“角色”、“名称”设置更高的统计目标，然后再进行分析，您也可以为您的原始查询制定一个好的计划。例如：

ALTER TABLE "Roles"
  ALTER COLUMN "Name" SET STATISTICS 1000;
ANALYZE "Roles";

如果它预计表中存在较少的匹配行，因为它可能会处理更细粒度的统计信息，它会假设它需要读取更高百分比的表才能在顺序扫描中找到它们。这可能会导致它更喜欢使用索引而不是顺序扫描表。

您还可以通过调整计划器的一些成本常数和缓存假设来为原始查询制定更好的计划。您可以在单个会话中尝试使用SET 命令：

• 减少random_page_cost。这主要取决于缓存数据的严重程度。给定一个包含数亿行的表，您可能不想低于 2；尽管如果您的数据库中的活动数据集被大量缓存，您可以将其一直减少到seq_page_cost 的设置，并且您可能希望将它们都减少一个数量级。

• 确保 Effective_cache_size 设置为 shared_buffers 和您的操作系统正在缓存的任何内容的总和。这不会分配任何内存；它只是告诉优化器在大量访问期间索引页保留在缓存中的可能性有多大。与顺序扫描相比，较高的设置会使索引看起来更好。

• 将cpu_tuple_cost 增加到 0.03 到 0.05 范围内的某个位置。我发现默认值 0.01 太低了。我经常通过增加它来获得更好的计划，并且从未见过我建议的范围内的值会导致选择更糟糕的计划。

• 确保您的work_mem 设置合理。在我运行 PostgreSQL 的大多数环境中，大小在 16MB 到 64MB 之间。这将允许更好地使用哈希表、位图索引扫描、排序等，并且可以完全改变您的计划；几乎总是变得更好。如果您有大量连接，请注意将其设置为产生良好计划的级别 - 您应该考虑到每个连接都可以为它正在运行的查询的每个节点分配这么多内存的事实。 “经验法则”是计算您将在此设置时间max_connections 附近达到峰值。这是使用连接池限制实际数据库连接数是明智之举的原因之一。

如果您找到这些设置的良好组合，您可能希望对您的postgresql.conf 文件进行这些更改。如果您这样做，请密切监控性能回归，并准备调整设置以实现整体负载的最佳性能。

我同意我们需要做一些事情来让优化器远离“有风险”的计划，即使它们看起来平均运行得更快；但是，如果调整您的配置以使优化器更好地模拟每个替代方案的实际成本并不会导致它使用有效的计划，我会感到有些惊讶。

Answer 2

终于成功尝试

我的另一个想法 - 根据评论：
如果在未找到角色的情况下删除 LIMIT 子句，会发生什么情况？我怀疑这会导致快速计划 - 让 LIMIT 成为这里的罪魁祸首。

您可以通过将查询下推到 子查询 并将 LIMIT 仅应用于外部查询（未经测试）来解决您的问题：

SELECT *
FROM  (
   SELECT *
   FROM   "Roles"         AS r  
   JOIN   "Users"         AS u  ON u."RoleId" = r."Id"
   JOIN   "PaymentOrders" AS po ON po."UserId" = u."Id"
   JOIN   "Payments"      AS p  ON p."PaymentOrderId" = po."Id"
   WHERE  r."Name" = 'Moses'
  ) x
LIMIT  1000;

根据评论：@Davita 测试并排除了这种解决方法。 @Kevin's answer 后来澄清了解决方法失败的原因：使用 CTE 而不是子查询。
或者在使用大查询消除不良情况之前检查角色是否存在。

这给 PostgreSQL 留下了关于使用 LIMIT 优化查询的问题。

有很多recent bug reports concerning query plans with LIMIT。我引用 Simon Riggs 对其中一份报告的评论 here：

使用 LIMIT 的非常糟糕的计划很常见。这对我们不利，因为 添加 LIMIT 通常/应该使查询更快，而不是更慢。

我们需要做点什么。

第一次尝试没有成功

我错过了 @Craig 在 cmets 中已经提到的 join_collapse_limit。所以这是有限的用处：

重新排序JOIN 子句有什么效果吗？

SELECT *
FROM   "Roles"         AS r  
JOIN   "Users"         AS u  ON u."RoleId" = r."Id"
JOIN   "PaymentOrders" AS po ON po."UserId" = u."Id"
JOIN   "Payments"      AS p  ON p."PaymentOrderId" = po."Id"
WHERE  r."Name" = 'Moses'
LIMIT  1000

相关：join_collapse_limit 或geqo_threshold 的设置不是偶然弄乱的吗？ 非常低的设置可能会阻止规划器重新排序您的 JOIN 子句，这可能会解释您的问题。

如果这不能解决问题，我会尝试在"Roles"(Name) 上创建一个索引。并不是说这仅对 15 行有任何意义，但我会尝试消除无效统计或成本参数（甚至是错误）使规划者认为对“角色”进行顺序扫描比实际更昂贵的怀疑。