物化视图 VS 表: 有哪些优势?

我很清楚为什么物化视图比仅查询基表更可取。不太清楚的是,与仅仅创建另一个具有与 MV 相同数据的表相比,这样做的好处。MV 的唯一优势真的只是易于创建/维护吗?

MV 是否等价于使用 MVs SELECT 语句的具有匹配模式的表和 INSERT INTO?

也就是说,您可以按照以下方式创建 MV

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

您可以创建一个等价的表:

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

并不是说创建/维护的简单性不足以成为优势,我只是想确保我没有错过任何东西。

91133 次浏览

Table 和 MV 的区别在于 table,你可以执行 DML 操作,这些操作会被其他用户看到,而你对 MV 所做的更改在你更新数据库服务器之前不会被其他人看到。

MV 还有另一个优点,当你使用复杂的查询基于多个表构建 MV 时,用户使用 MV 时性能大大提高。

它们基本上是等价的,但是 MV 有各种自动刷新数据的选项,这不仅提高了维护的易用性,而且在某些情况下还提高了效率,因为它可以逐行跟踪更改。

物化视图可以刷新——它们是定期采集的数据快照。

你的第二个声明只是一次交易-数据被插入表格在那一刻。对原始数据的进一步更改不会反映在表中。

物化视图的最大优点是极快地检索聚合数据,因为它是预先计算和存储的,代价是插入/更新/删除。该数据库将保持物化视图与真实数据同步,不需要重新发明轮子,让数据库为您做。

动态查询重写 。物化视图不仅定义关系,还允许预先计算开销较大的联接和聚合。即使 MV 没有在查询中显式使用(给定 DB 设置等) ,优化器也足够聪明地使用 MV 来获取相关数据。

您的问题被标记为 Oracle,但 MSSQL 也有类似的技巧。

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

  1. 物化视图将与基本关系保持同步 它取决于

  2. 如果物化视图是可更新的,则在修改 物化视图,它也会修改它所依据的基本关系 看情况

1) 加速写操作: 由于索引可以在物化视图上创建,从它们读取非常快。注意,如果在包含大量写操作的表上创建索引,索引维护开销往往会降低写操作的速度。为了避免这种情况,您可以创建一个具体化视图并为它们创建索引。这些索引可以在后台维护,并且不会对表写操作产生不利影响。

2) 加速读操作: 复杂的连接; 可以通过在物化视图上创建索引来加快运行时间长的枢轴。这在大多数报告场景中都非常方便。

除了已经提到的好处之外:

  • 动态查询重写(简而言之,DB 优化器知道如何创建 MV,因此可以重用它来优化其他查询) ,
  • 可选的,自动的,可能是增量刷新,

我想提一下:

  • 可以写入一些物化视图,它们更新源表(例如,可以写入带有主键的连接,相反,如果物化视图是无法写入的组的结果,则可以写入)
  • DB 服务器保留创建数据的查询并可以重新运行它。如果创建表,则需要一个外部工具(可能只是一个自定义脚本) ,以便在用户需要/请求刷新时重新运行查询。(我在一家公司工作,公司正在开发一种可以做到这一点的工具。)。

实体化视图实际上是定期需要聚合以显示更新结果集的表的最佳选择。 我们可以使用物化视图来计算每天、每周、每月的库存,而不必每次都使用复杂的查询,我们可以使用物化视图来在短时间内获得这样的结果。

我想正确的比较应该是:

REFRESH MATERIALIZED VIEW bar;

对比:

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

因为 MV 你可以做一次,并刷新时,你需要作出选择(甚至节省一些电话,如果你知道如何频繁的信息变化)

你也可以提供和索引到 MV,这是你没有其他方式。当然,这将有利于 MV 的性能,只有在大的结果集。

在邮报中你也可以这样做:

REFRESH MATERIALIZED VIEW CONCURRENTLY bar;

通过两个并行进程刷新它,如果一个还没有结束,另一个需要的信息,直到该时刻的时间。我猜测已经进行了一些优化,以重用正在运行的查询中的内容。

您不能使用 SELECTINSERTINSERTINTO 进行此操作。

当 Oracle 遇到复杂的查询时,执行该查询将花费更多的时间。如果用户想减少执行时间,那么物化视图是最好的选择。首先我们必须创建物化视图与该查询创建后,我们可以简单地使用物化视图而不是基表。