视图计算列如何影响性能？

Question

我从this question 了解到，SQL 语言确实支持视图中的计算列。

我有一个要求，我有一个包含多个列的表，并且我需要计算一个排序列以简化我的查询。我正在考虑为我的原始表创建一个视图，并计算出那些排序列。但我担心随着我的桌子越来越大，这可能是一场性能噩梦。

有人知道这会如何影响性能吗？

是否可以在视图中的计算列上创建索引？

---

更新 1： 我计划使用 postgresql，但我对 MySQL 等其他开源替代品持开放态度

---

更新 2： 正如N.B. 建议的那样：

我不是 Postgres 用户，但docs here 正在展示如何创建该视图以及如何为其编制索引。如果您正在使用 Postgres 并且熟悉它 - 坚持下去。所有数据库的工作方式几乎相同，但如果您更精通其中一个 - 没有理由更改它。至于它如何影响性能——无论是动态构造的视图还是查询——都是一样的。 View 在查询时只是一个巨大的帮助，如果你可以索引它，这意味着一些内存将花费在索引上。你必须测量

我现在认为物化视图是满足我的功能需求的方法，一旦我确认这一点，我可以设置一个触发器来刷新我表上的每个更新的物化视图：

• REFRESH MATERIALIZED VIEW 是如何工作的？它会删除数据并从头开始重新创建视图吗？还是会进行某种差异刷新？

Answer 1

免责声明：我在远程服务器上同时使用 MySQL 和 PostgreSQL 数据库大约 8 个月，并且我更喜欢 PostgreSQL 来满足您的用例。

TL;DR

1. 根据文档，REFRESH MATERIALIZED VIEW 如果添加 WITH DATA 子句，命令将删除所有数据并重新填充整个查询的数据。
2. 您可以为物化视图创建索引。索引可能位于列中存储的计算字段上。
3. 您不能索引视图（非实体化）
4. 您可以根据需要创建不同类型的物化视图（请参见下面的 URL 链接）。

详细说明

A) 物化视图类型和性能

我有一个要求，我有一个包含多个列的表，并且我需要计算一个排序列以简化我的查询。我正在考虑为我的原始表创建一个视图，并计算出那些排序列。但我担心随着我的桌子越来越大，这可能会成为一场性能噩梦。

如果计算非常昂贵，请考虑消耗更多内存来将结果存储在物化视图或表中。

物化视图就像一个存储查询结果的表。对于 PostgreSQL 物化视图，可以在其上创建索引以加快查询速度，并且可以对其进行清理以更新元数据。

PostgreSQL 提供的物化视图是一种幼稚的视图，因为您必须使用REFRESH MATERIALIZED VIEW 命令手动刷新数据。根据文档，如果您添加 WITH DATA 子句，这将删除所有数据并重新填充数据。

之后，需要考虑插入、更新、删除操作所需的性能：

1. 如果您没有实时要求（即完整的表 重新填充是可以接受的）那么这个选项很好。
2. 否则，您可能希望查看此网站帖子以了解不同的物化视图设置，其中一些允许延迟刷新数据（按行触发刷新数据） https://hashrocket.com/blog/posts/materialized-view-strategies-using-postgresql

第二点也适用于 MySQL（实际上是构建物化视图的传统和定制方式）。据我所知，MySQL 不支持开箱即用的物化视图（需要插件）。 (1) 中提供的便利性是我选择 PostgreSQL 的原因之一。

是否可以在视图中的计算列上创建索引？

可以为实体化视图的列建立索引，就像为表做索引一样。

B) PostgreSQL 中的窗口函数

选择 PostgreSQL 而不是 MySQL 的第二个原因是前者提供了扩展的 SQL 函数（或者我想称它们为 OLAP 函数），以帮助处理复杂的查询，如行排名等。

我将留给你探索这个选项（只需在“PostgreSQL 窗口函数”上进行谷歌搜索）。

根据我的最新知识，MySQL 对此没有内置支持（可能依赖插件或自己的​​编码？）。