我有一个基于 Postgresql 的数据仓库。
直到现在，我一直在尝试在一个只包含我真实数据库的一小部分的数据库上运行查询。一旦我以一种使它们对这个小型测试数据库有效的方式编写了查询，我就会在真实的数据库上运行查询。
问题是，一旦我在真实数据库上运行查询，真实数据库就会耗尽内存并开始将索引和临时表等内容写入磁盘。这意味着对于测试数据库和真实数据库，不同的查询可能是最佳的。这是否意味着我真的必须运行需要几分钟才能完成的查询才能知道哪个查询是最佳查询。
【问题讨论】：
标签： database postgresql database-performance
了解如何解释EXPLAIN 输出，然后在运行查询之前检查EXPLAIN 输出是否表明您的大型数据库中选择的查询计划与您的预期相似。
【讨论】：
三个问题：
1) 查询有多复杂？索引和临时表的生成表明，由于对未索引列的复杂操作，服务器必须生成这些东西。这可能性有多大？根据您的报告，可能的答案似乎是“复杂”
2) 返回集有多大？最终结果是 100 行还是 100 万行？根据您的报告，答案可能是任何东西。我怀疑这个问题没有那么重要，但至少知道这一点很重要。
3) 以不同的方式重述问题1，即使返回的集合很小，是否有大量的中间结果必须在得到小结果的过程中被编译？同样，我怀疑这里的答案是正在生成大量复杂的中间结果。
这表明至少需要对某些内容进行索引，并且可能需要在输入的过程中对数据进行结构化以更接近您要查询的内容。
最后一个问题，对于大多数更重要的查询来说，这是一个普遍存在的问题，还是只针对一两个？
编辑回复评论：我整天都在做数据仓库查询，其中一些需要 10 分钟左右。有些需要几个小时，我把它们推到后台工作，然后把它们分成几个阶段，以防止一切都陷入困境。这就是处理非常大的数据集的本质。
我在原始答案中的问题旨在确定您的问题查询是否会永远完成。可能会在不知不觉中编写一个查询，该查询会产生如此多的中间数据，以至于您可以走开，2 天后回来，它仍在运行。所以我会重申我最初的三个问题，它们实际上是完全回答你的问题的唯一方法。
回顾：是的，有些查询需要更长的时间，这是野兽的本性。您可以期望的最好的结果是与正在读取的数据量成线性关系的性能，如果要处理 1 亿行，那将需要几分钟而不是几秒钟。但更重要的是，如果一个查询在 4 秒内运行 100 万行，但在 1 亿行上需要 >> 400 秒（比如一个小时），那么我提出的那些原始问题将帮助您找出原因，以优化那些查询。
【讨论】：