Question

我很清楚为什么物化视图比查询基表更可取。不仅仅是创建另一个具有与MV相同数据的表的优势还不是很明显。 MV的唯一优势还在于创建/维护的简易性吗？

使用MVs SELECT语句，是不是MV等效于具有匹配模式的表和INSERT INTO？

意思是，您可以按如下方式创建MV

CREATE MATERIALIZED VIEW ... AS
SELECT * FROM FOO;

您可以创建一个等效表：

CREATE TABLE bar (....);
INSERT INTO bar 
SELECT * FROM FOO;

并不是说创造/维护的便利性不足，我只是想确保我没有遗漏任何东西。

Answer 1

Dynamic query rewriting。物化视图不仅定义关系，还允许您预先计算昂贵的连接和聚合。即使未在查询中明确使用MV（给定数据库设置等），优化器也足够智能使用MV来获取相关数据。

你的问题被标记为Oracle，但MSSQL也做了类似的技巧。

Answer 2

它们基本相同，但MV有各种自动刷新数据的选项，这不仅提高了维护的便利性，而且在某些情况下还提高了效率，因为它可以按行跟踪更改。

Answer 3

可以刷新物化视图 - 它们是定期拍摄数据的快照。

你的第二个陈述只是一次性交易 - 当时数据被插入到表中。对原始数据的进一步更改不会反映在表中。

Answer 4

物化视图的一大优势是可以非常快速地检索聚合数据，因为它是预先计算和存储的，但代价是插入/更新/删除。数据库将使物化视图与实际数据保持同步，无需重新发明轮子，让数据库为您完成。

Answer 5

Answer 6

除了已经提到的优点之外：

我想提一下：

可以写入一些物化视图，更新源表（例如，可以写入与主键的连接，相反，如果物化视图是组的结果，则可以写入到）
DB服务器保留创建数据的查询，并可以重新运行它。如果创建表，则需要外部工具（可能只是自定义脚本），以便在用户需要/询问刷新时重新运行查询。（我为一家开发工具的公司工作，并且更多）。

Answer 7

除了其他答案（因为我还没有看到它），我会说虽然它们都占用空间，但物化视图在逻辑上是标准化的，而额外的表是逻辑非规范化的。如果这不是临时的一次性，那么每当更新基表时，都必须记住更新第二个表。

Answer 8

1）加速写入操作：由于可以在物化视图上创建索引，因此从它们读取速度非常快。请注意，如果在包含大量写入的表上创建索引，则索引维护开销会降低写入过程的速度。为避免这种情况，您可以创建一个实体化视图并在其上创建索引。这些索引可以在后台维护，不会对表写操作产生负面影响。

2）超速读取操作：复杂连接;通过在物化视图上创建索引，可以加快需要运行时间的枢轴。这在大多数报告方案中变得非常方便。

Answer 9

表和MV之间的区别在于表，您可以执行其他用户可以看到的DML操作，而在更新数据库服务器之前，您对MV所做的更改将无法用于其他人。

当使用复杂查询基于多个表构建MV时，MV具有另一个优势，使用MV时用户的性能会大幅提升。

Answer 10

在需要定期进行汇总以显示更新结果集的表上，实际上对视图进行可视化是最好的选择。除了使用库存模块中的数据仓库外，我们还可以使用物化视图来计算具有结余余额的每日，每周，每月库存，而不是每次都使用复杂的查询，我们可以使物化视图立即获取此类结果。

Answer 11

我猜正确的比较是：

REFRESH MATERIALIZED VIEW bar;

与之相对：

CREATE TABLE bar (....);
INSERT INTO bar 
SELECT * FROM FOO;

由于MV，您可以制作一次，并在需要进行选择时刷新（如果您知道信息的更改方式，甚至可以省掉一些电话）

此外，您可以提供MV并为其建立索引，而这是您所没有的。当然，这只会对大型结果集有利于MV的性能。

在postgres中，您还可以这样做：

REFRESH MATERIALIZED VIEW CONCURRENTLY bar;

通过两个并行过程刷新它，如果一个还没有结束，而另一个需要及时的信息。我猜想已经做了一些优化以重用正在运行的查询中的内容。

这是您无法使用SELECT INSERT INTO进行的操作。

Answer 12

当 Oracle 遇到复杂查询时，执行该查询需要更多时间。如果用户想减少执行时间，则物化视图最适合。首先，我们必须在创建后使用该查询创建物化视图，我们可以只需使用物化视图而不是基表。