这听起来可能有很多行话，所以让我们通过一个例子来让这个想法变得真实。

假设我有三个基表：Staff、Items 和 Sales。 Items 表存储不同项目的记录。在这种情况下，我们正在研究不同的厨房用具。同时，Sales 表使用 Sales 表中的外键 itemId 包含每个商品的销售记录。

我可以创建一个名为 sales_by_item 的物化视图，它聚合每个商品的总销售额。这可以直接从 Sales 表完成，也可以通过引用 Items 和 Sales 表的 JOIN 语句完成。这对我需要视图中更详细的数据很有帮助。

何时使用物化d 视图

在现实世界的系统中，物化视图在四个关键领域是有益的：

减轻网络负载。 创建大规模部署环境。 启用数据子集化。 启用断开连接的计算。

下面，我将讨论每个用例，以便我们了解为什么物化视图支持这些目标。

减轻网络负载

在多个地点运营的组织严重依赖网络进行通信。然而，使用我的系统的人越多，它所承受的压力就越大。为了避免因流量增加而需要进行成本高昂的网络升级，我可以减少网络流量。

只读物化视图在帮助分配网络负载方面已经改变了游戏规则。通过在靠近员工工作地点的各个地理区域复制数据库，我可以防止源数据库中的数据冲突。这种方法比让整个公司从单个服务器访问数据要高效得多。

拥有多个服务器在不同的位置，您的物化视图将在离您最近的服务器上运行。行驶距离越短意味着信息加载速度越快，查询完成得越快。您可以避免增加存储成本和许多与速度相关的问题。

我可以通过高效的批处理过程从单个源或主物化视图站点更新这些物化视图。此过程的网络要求和依赖性较少，仅复制特定时间点并且仅需要定期刷新。

此外，我可以基于其他物化视图创建物化视图。这种策略使我能够更有效地分配用户负载。客户端可以访问物化视图站点而不是源站点。这进一步减少了需要复制的数据量。

创建大规模部署环境

作为数据库管理员，大规模部署工具使我能够快速交付数据库基础设施演讲和数据。这意味着我可以在维护的同时管理不同站点的信息。

使用部署模板可以轻松定义物化视图。这意味着他们特别支持大规模部署。通过使用这些模板，我可以一次性指定物化视图环境的结构。然后，我可以在多个站点上复制它，而不是重新发明轮子。

我还可以调整模板参数，使我能够自定义每个物化视图环境。这种灵活性使得与不同数据使用者共享特定数据类型变得更加容易。

通过物化视图进行大规模部署让我可以快速将信息分发到各个端点。这意味着我可以将数据发送给现场技术人员、远程库存站点、零售商店和移动销售人员。这种方法显着提高了我的效率。

启用数据子集化

我可以使用物化视图从源复制数据子集呃行级或列级子集。这意味着我花更少的钱复制特定于某些站点的数据。此方法比需要完整表复制的替代方法更有效。

数据子集化允许我创建仅包含整个数据库的部分内容的副本。然后我可以只关注我需要的信息。

例如，假设我有一个包含多个部门员工的组织数据库。我可以使用具体化视图来复制特定于一个部门的数据以供内部使用。

此方法还允许我通过物化视图和子集设置来强制执行一定程度的安全性。我可以确保只有相关数据才会暴露给授权人员。

启用离线计算

由于物化视图是（大部分）实时数据库的派生，因此我不需要专用的网络连接来让它们工作。在我的标准实践中，尤其是在使用本地化应用程序时，我经常选择手动刷新物化视图。但是，可以通过作业调度来自动化此过程。

手动按需刷新物化视图（而不是使用连续的）对于在个人计算机上运行的销售应用程序效果很好。

例如，作为开发人员，我可以将用于按需刷新的复制管理 API 集成到销售应用程序中。当销售人员完成当天的订单后，他们只需拨号网络并使用复制管理 API 将订单传输到主要办公室。仅在刷新过程中才需要网络连接。

物化视图的最佳实践

就像标准查询一样，我发现有必要优化物化视图。我使用的大多数数据库的基本关系都会随着应用程序级事务而不断变化。

根据我对物化视图的经验，如果视图重新定义，性能可能会很笨拙。需要不断更新以反映基础关系的变化。为了解决这个问题，我可以通过重新定义生成物化视图的初始表达式来获得更好的结果。

我们将在下面深入探讨这一最佳实践等。

创建物化视图

当我创建物化视图时，我会优先考虑资源密集型流程。此策略允许视图存储数据类型，从而减少频繁执行复杂查询的需要。这意味着您可以节省时间，更重要的是，节省电力。

此外，我发现您可以从同一基本关系派生出多个物化视图。一个视图可能保存表的最新数据，而另一个视图则捕获同一关系中的异常数据。使用非物化视图，我可以连接这两个视图，即使它们最初是作为物化视图创建的。

生成的视图非常有洞察力，经常揭示可能表明关键问题的数据异常就像数据库一样。

在我的实践中，我考虑仅在基本关系不聚集的数据库中为异常数据构建物化视图。如果我已经在基表的集群键中指定了包含异常数据的列，我也会使用此方法。

此外，只有在易于隔离的情况下，我才会选择针对异常数据的物化视图。我了解到，维护很少使用的数据的物化视图的成本可能会超过收益。

优化基表操作

正如我之前指出的，在使用物化视图时我面临的一个常见挑战是它们与定期更新的基表之间潜在的不一致。为了解决这个问题，我考虑在基表上批量处理数据操作语言 (DML) 操作。

例如，使用 DELETE 操作是我从表中删除旧数据的常见做法。如果我有基于此类表的物化视图，请将它们更新为反映这些变化至关重要。但是，频繁更新会增加后台性能和存储成本。为了管理这些成本，我每周或每月对表执行批量删除操作。

对于 INSERT、MERGE 和 UPDATE 等其他过程，事实证明，根据数据库中的基本关系对它们进行批处理也可以有效降低从这些表派生的物化视图的维护成本。

除了创建物化视图之外，我还创建视图日志和自定义按需视图刷新。我知道 Oracle 和其他数据库中可以为物化视图定义更复杂的操作。要了解更多信息，您可以查看。

使用物化视图简化数据分析

我怎么强调物化视图给数据库驱动系统带来的价值都不过分。它们减少了在数据库上运行本机查询所带来的性能瓶颈和成本。这对于存储数据的生产环境来说是巨大的节省a 可以是可扩展的。

在补充资源密集型查询时，我总是考虑物化视图。此外，对数据库进行批处理 DML 操作是我用来降低性能成本的策略。这种方法极大地提高了我管理的数据库系统的效率，希望这种方法也能帮助到您。

编者注：本文最初于 2022 年 10 月发布，为了全面性已进行更新。

来源：hubspot