我害怕db中的奇怪行为，在我的主表UDBMOVEMENT_ORIG（26mil.rows）和UDBIDENTDATA_ORIG（18mil.rows）上创建物化视图TMP_MS_UDB_MV（{{1这个对象的同义词）满足某些默认条件并在这些主表上连接条件。 MV大约有12亿行。我创建MV来查询不是那么大的对象，MV得到3GB，主表到12GB。但我不明白，即使物理读取和一致获取在MV上比在主表上更少，主表上的最终执行时间也更短。请参阅下面的日志。
为什么？
UDBMOVEMENT感谢您的回答。
答案 0 :(得分：3)
我假设所有表/ MV都收集了适当的统计数据。
如果你查看第一个查询的计划，你会看到我们在UDBMOVEMENT_ORIG上有一个RANGE SCAN，然后对于找到通过where子句的每一行，我们有一个INDEX UNIQUE SCAN { {1}}（可能是它的PK）。请注意，Oracle已将您的OUTER JOIN转换为标准的INNER JOIN（NESTED LOOP）。
第一步返回几行（＆lt; 10k），因此第二步接下来没有时间。因此，我们可以假设第一个查询的大部分工作都花在寻找与where子句的标准相匹配的行上。 DB选择使用UDBIDENTDATA_ORIG索引。我们错过了它的定义，但由于查询计划，我们可以猜测它涵盖了列（IDX_UDBMOVARTICLE）。
第二个查询是直的TACTIONTIME, SARTCLASSREF，我们再次错过了索引定义，但我们再次猜测它会覆盖列（RANGE INDEX SCAN）。
我的结论是你在原始表及其MV上没有相同的索引，所以你看到查询时间（苹果和橘子）的差异就不足为奇了。具有讽刺意味的是，较小的原始索引比该查询的对应更合适。
我还要指出数据库非常擅长加入，而且在大多数查询中，您只会看到预加入表的边际收益。你有时甚至可以看到负增益，因为MV将被去标准化，因此更大（因此全扫描更昂贵）。
答案 1 :(得分：0)
如果你查看排序统计信息，那么较慢的查询所执行的排序数量几乎是快速查询的两倍：
86 sorts (memory)
VS
168 sorts (memory)
这将在某种程度上解释为什么第二个查询较慢，但我怀疑单独的排序是整个原因。时间增加的原因可能与文森特所确定的指数差异有关。我怀疑有很多原因可以使它整体变慢。