慢查询问题/es

慢查询指南

在任何一个星期内，IRC 的 #postgresql 频道中约有 50% 的问题和 pgsql-performance 中约有 75% 的问题是关于慢查询的帮助请求。但是，提问者很少会发送关于慢查询的完整信息，这不仅让提问者感到沮丧，也会让尝试帮助他们的人感到沮丧。

因此，在发送“我的查询很慢”之前，请获取信息并遵循以下列出的建议。此外，请检查并发布 问题报告指南 中的相关信息。

在阅读 wiki 性能类别 中可用的资源、收集相关信息（见下文）并思考问题之后，请将与性能相关的问题发送到 pgsql-performance 邮件列表。在点击“发送”之前，请尝试以不知道任何有关你的配置或应用程序的人身份阅读你的邮件，并检查你的问题是否有道理。在你获得足够的信息帮助你之前，它将帮助你节省多次收到“没有解释 <某事>”或“<某事> 是什么意思？”等类型的答复 - 做一些努力，可以让你更快地获得更好的答复。

你需要发送的信息

（注意：如果你在 IRC 中寻求帮助，请将此内容发布到例如 [pgsql.privatepaste.com] 的网站上，而不是直接发布到 IRC 频道中）

• 表和索引架构：发布查询中引用的所有表和索引的定义。如果查询触及视图或函数，那么我们也需要这些定义。

• 表的元数据：除了表的定义外，请发布表的近似行数，以及表的任何异常情况，例如
  • 包含大对象 (large objects)
  • 在多个列中具有大量的空值
  • 定期收到大量的 UPDATE 或 DELETE
  • 增长快
  • 有许多索引
  • 使用可能调用其他数据库函数的触发器，或直接调用其他函数

• EXPLAIN ANALYZE，而不是仅用 EXPLAIN：EXPLAIN ANALYZE 会告知我们查询实际执行的方式，而不仅仅是预期的执行方式。该信息对于发现计划程序使用的一种低效计划，而不是其他任何计划，至关重要。如果无法执行 EXPLAIN ANALYZE，这是因为该查询永远无法完成，请指明这一点。更好的是，将 EXPLAIN ANALYZE 结果粘贴到 explain.depesz.com，然后发布生成后的链接。我们很乐于这样做，因为它使我们更容易地阅读和研究计划。

• PostgreSQL 版本：请提供您使用的服务器的确切版本 (SELECT version() 是一个轻松获取版本的方式)。计划程序的行为在每个版本中都不同，所以这一点很重要。

• 历史记录：该查询一直很慢，还是随着时间的推移变得越来越慢？如果查询使用的执行计划不同，您就没有查询计划的副本吗？您的数据库中是否在不同的数据累积期间发生过更改？

• 硬件：请发送有关您的硬件平台的基本信息。如果某个硬件元素不寻常，请提供有关该元素的详细信息。参见 故障报告指南 以了解哪些类型的硬件信息有用。

• 维护设置：您是否正在运行 autovacuum？如果是，使用什么参数？如果不是，您是否正在执行 VACUUM 和/或 ANALYZE？频率如何？

• WAL 设置：(对于执行写入的查询) WAL 已经更改到不同的磁盘了吗？设置是否已更改？

• GUC 设置：您更改了哪些数据库配置设置？设置值是什么？（这些是“work_mem”、“enable_seq_scan”等内容。）参见 服务器配置，获取一个有用的查询，显示从默认值更改的参数，以一种比发布 postgresql.conf 摘录更易于阅读的方式。

在编写前尝试的事情

如果您在编写问题前尝试以下几项操作，则可以节省很多时间

• 如果您还没有阅读，请阅读 使用 EXPLAIN。
• 分析数据库以更新查询统计信息。
• 对数据库执行 VACUUM 以进行清除，如果您尚未运行 Autovacuum。
• 检查主要 GUC 设置以确保其适合合理的值（参见 调整 PostgreSQL 服务器 以获取其他线索）
  • shared_buffers 应为可用 RAM 的 10%-25%
  • effective_cache_size 应为可用 RAM 的 75%
• 尝试更改 Work_mem：将数量增加到 8MB、32MB、256MB、1GB。有什么区别？
• 针对 Insert/Update/Delete 查询，还应测试 WAL 的配置
  • 如果可能，将 pg_xlog 移动到单独的磁盘资源
  • 将 checkpoint_segments 增加到 16 或更高（假设有磁盘空间）
  • 将 wal_buffers 增加到 16MB
• 测试您的 I/O 设备：尝试运行 dd、bonnie++ 或其他速度测试以查看您的性能问题是否仅仅是基于硬件。例如，无论如何调整查询，RAID-5 配置的插入和更新速度都不会很快。