mysql - View 性能增益在现代 RDBMS 中是否仍然相关

Question

毫无疑问，编写 SELECT * FROM viewCostumerAddress 比 SELECT c.id,c.name,a.id,a.fullAddress FROM customer c JOIN address a on 更简单直观a.id_costumer=c.id ORDER BY a.id,c.Priority，但是当一群人告诉你“ View 的性能更好”而你的测试并没有显示你所做的这样的增益时?
我进行的所有测试都使用相同的 SQL Server 2014。数据集有大约 2kk 个客户端和 2.5kk 个地址。任何时候，服务器内存消耗都不会超过 60%。冷查询测试之后始终是完整的服务重启，以“强制清除”任何预编译查询和任何缓存信息。热查询的结果仅在每个查询/ View 被命中 200 次后才被记录，尽可能多地过滤不同的值。所有测试都在专用而非虚拟服务器(裸机)上进行了 1000 次。
然而，热查询的最终结果差异小于 1% (0.971%)，冷查询的差异几乎为 0 (0.0024%)。

面对这些结果，我开始怀疑在现代 RDBMS 世界和“对象关系映射器”中，旧的性能提升声明是否仍然是从 View 而不是直接从表查询数据的有效理由？

PS:请尽量在您的回答中做到科学，提供测试方法(如果适用)和/或科学论文，或者在报告您 亲眼目睹。

Answer 1

如果您有一个不是索引 View 的普通 View ，则不会提高性能。这是因为，当您从 View 中选择时，SQL-Server 运行 T-SQL-Statement 就像没有 View 一样。

以下是我对观点的一些看法:

<强>1。 View 是安全层

我个人不希望任何人直接访问我的基表。在 View 中，我可以根据调用者的许可过滤掉行。在 SQL Server 2014 之前，您无法对表执行此操作。

<强>2。 View 正在返回一组特定的列

如果我必须更改基础表的模式，我可以以某种方式更改 View ，它返回与以前相同的列。如果您不使用 View 并且用户自己从基表中进行 SELECT，查询可能会失败。

<强>3。 View 正在节省开发时间

您不必一遍又一遍地编写相同的 T-SQL 语句。如果 T-SQL-Statement 中有错误怎么办？只需将它固定在一个地方，在 View 中。您可能不必更改应用程序或许多功能和存储过程。

<强>4。使用索引 View 加速 SELECTs

当您发现 View 中的 INNER JOIN 开销太大并且没有更多其他选项(如有用的索引或模式更改)时，您可以使用索引 View 来加速 SELECT。但是您可能会在 INSERT、UPDATE 和 DELETE 上降低性能，因为 View 的索引也必须更新。