Sql 多个小查询比一个大查询快

下面的“大”查询运行24小时以上：

SELECT * 
FROM VIEW 
WHERE COL_A IN (a, b, c, ...) 
  AND COL_B IN (d, e, f, ...)

相反，将此“大”查询划分为多个“小”查询并同时执行它们只需30分钟：

SELECT * 
FROM VIEW 
WHERE COL_A IN (a) AND COL_B IN (d)

SELECT * 
FROM VIEW 
WHERE COL_A IN (a) AND COL_B IN (e)

...

SELECT * 
FROM VIEW 
WHERE COL_A IN (b) AND COL_B IN (d)

SELECT * 
FROM VIEW 
WHERE COL_A IN (b) AND COL_B IN (e)

...

如果相关的话，“big”查询中的每个IN语句包含大约30项。因此，900个唯一的“小”查询=1个“大”查询

请注意，

VIEW

被定义为对

VIEW\u 1

的查询，它本身就是对

VIEW\u 2

的查询，而

VIEW\u 3

本身就是对

的查询。每个视图都有数百万行长

我会对视图进行反向工程，并为我想要的内容编写我自己的单一查询。但是，我没有对基础表的SELECT访问权限

当返回的表相同时，以编程方式并行编写和执行900个不同的查询（使用Python）比执行一个大查询要快，这似乎与直觉相反。为什么会这样

附件是
解释计划
中200个操作的一个片段
 首先，您可以将这些作为一个查询运行：

SELECT * FROM VIEW WHERE COL_A IN (a) AND COL_B IN (d)
UNION ALL
SELECT * FROM VIEW WHERE COL_A IN (a) AND COL_B IN (e)
UNION ALL
. . .

听起来基础表在视图上有索引。您可能还可以将查询简化为：

SELECT * FROM VIEW WHERE COL_A = a AND COL_B IN (d, e, . . .)

或：

原因很多。像这样嵌套视图是一个已知的性能瓶颈。优化器生成计划的毫秒数有限。一旦超时，它将使用“最佳”。这可能根本不是一个好计划。如果您的查询有数百万行，这将不是一个好的计划。在

操作符中有大量的

会被优化器扩展到
或
，当你有900个操作符时，这同样会导致糟糕的计划。在这里，许多小“糟糕”相互叠加，形成了一个巨大的性能黑洞。@JacobH感谢您的详细回复！如果我不能对视图进行反向工程并编写自己的查询（不选择对基础表的访问），那么除了让DB团队创建新视图之外，我最好的选择是什么？仅仅是继续使用Python以编程方式编写数百个查询，同时执行它们，然后合并结果吗？注释太长了，但这里有一个很好的开始链接，如果您真的想获得这方面的帮助，您需要在查询上发布
EXPLAIN ANALYZE
的输出。可能存在一些非常明显的问题，例如在客户端连接上缺少工作记忆。使用30个联合ALL并不是解决这个问题的好办法。@Ramfjord谢谢。我附上了解释计划的一个片段。有什么明显的修复方法吗？谢谢！明天我将测试并报告此方法的时间-使用30条UNION ALL语句执行单个查询。@Jack。首先测试其中一个，看看哪个版本更快。
SELECT * FROM VIEW WHERE COL_A IN (a, b, . . .) AND COL_B = d