视图与新表的数据库性能

Question

我正在使用性能较慢的Oracle数据库,因为在某些表上连接以获得结果.我正在考虑创建一个存储这些数据的新表,以便可以快速检索它而无需执行连接.另一种方法是为我正在执行的连接创建一个视图,然后始终查询视图以获取数据.使用新表与创建视图之间的性能折衷是什么？我认为一个视图仍然需要运行连接,因此它不会提供与新表一样好的性能.

有关Oracle数据库视图的信息,请访问:http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8004.htm - Oracle中的View是什么？

根据以下回复进行澄清.查询大部分已经过优化,因此我不想进行优化.更喜欢新表或物化视图,但想知道哪个可能更好.我对表演很感兴趣.编写更多代码以使新表与旧表保持同步不是问题.我只会在对旧表进行修改的地方添加修改语句.如果它比添加新表慢,我不想使用物化视图.

不同之处在于数据刷新对于物化视图还是新表更有效.对于新表,基本上我将在旧表更新的地方添加更新语句.因此,当用户查询新表时,数据已经存在(不需要进一步处理).但是对于物化视图,如果视图仅在用户查询视图时刷新自身,那么这可能会更慢.

Answer 1

视图只是一个存储查询,因此查询视图和对基表发出相同查询之间的性能应该没有差别.

创建单独的表可能会提高查询的性能,但它违反了规范化,然后您必须编写使该表保持同步的代码.如果您需要查询返回正确的结果而不是近似结果,这意味着您的DML操作(插入,更新和删除)将变得更慢,以便处理保持数据同步.如果这主要是一个报告数据库,那么这可能是一个适当的权衡,但在事务性能至关重要的OLTP环境中,它将更不合适.

如果您要创建一个表,我通常建议您考虑创建一个物化视图.这具有表的性能优势,但Oracle负责保持同步,因此您不必为此编写大量自定义代码.

但是,首先实现数据的具体化解决方案并不是很明显.你确定你不是只是错过了一些索引吗？

Answer 2

A materialized view可能是你正在寻找的.常规view不作为表存在,它只引用它所基于的表.但是,像Linutis评论的那样,您应该首先尝试优化查询.您可能需要连接中涉及的列的索引,以及您正在使用的表上收集的统计信息.

Answer 3

视图只是查询的包装器,使用视图的性能与使用查询的性能相同(如果忽略查询解析开销).

因此,如果使用大量连接,使用视图将无助于解决您的问题.但是经过Oracle中查询优化的大量经验,我可以给你一些注意事项:

1. 使用子选择(在select子句中)而不是在可能时加入; 在某些情况下,如果无法做到这一点,或者这样做不好,例如:
   • 当您使用内部联接从结果集中删除一些记录时 -
   • 你想在那些列上有一些条件
   • 你想对那些列进行排序.
2. 使用union all而不是union可以完成的地方.
3. coalesce在适当的时候使用,(即使使用sub-select作为参数),
4. 创建适当的索引(根据您的执行计划)
5. 避免在join和where子句中使用stored-functions.

这些是我现在想到的事情.希望它会有所帮助.