我有庞大的SQL查询。可能涉及15-20个表。 有6到7个子查询再次连接。 此查询大多数情况下需要一分钟才能运行并返回500万条记录。
因此即使这个查询编写得很糟糕,它确实有一个查询计划,可以在一分钟内完成。我确保查询实际运行并且没有使用缓存结果。
有时,查询计划会被抬高然后它永远不会完成。我每天晚上都会对查询中涉及的表进行真空分析。 work_memory目前设置为200 MB ..我已经尝试将此值增加到2 GB。当work_memory为2 GB时,我没有遇到过查询乱码的问题。但当我减少它并运行查询时,它变得混乱。现在,当我将其增加到2 GB时,查询仍然是混乱的。它是否与查询计划有关,没有使用新设置刷新?我在会议上尝试了丢弃计划。
我现在只能想到work_mem和真空分析。任何其他可能影响平稳运行查询的因素会在一分钟内返回结果并且不返回任何内容?
如果您需要有关任何设置的更多详细信息,请告诉我们?还是查询本身?我也可以粘贴计划......但是查询和计划还是太大了,不能粘贴在这里..
答案 0 :(得分:0)
如果范围表中有多个geqo_treshold
(通常为12个)条目,则遗传优化器将启动,通常会导致随机行为,如问题中所述。您可以通过以下方式解决此问题:
将geqo_treshold设置得太高(20可能太高......)会导致规划人员需要大量时间来评估所有计划。 (计划数量基本上随着RTE的数量呈指数增长)如果您期望您的查询需要几分钟才能运行,那么几秒钟的计划时间可能不会造成任何伤害。