创建物化视图或新表哪个更好？答案

【问题标题】：which is better, creating a materialized view or a new table?创建物化视图或新表哪个更好？
【发布时间】：2011-02-23 11:25:09
【问题描述】：

我有一些要求 mysql 查询必须从 5-7 mysql 表中选择相同的经常更新的数据集。 “选择”操作会比 CUD 多一点。

我正在考虑创建一个表或物化视图来收集来自其他表的所有要求高的列，从而减少对不同表的总体查询时间，从而提高性能。

如果我创建了那个表，每次更新其他表时我可能需要执行额外的插入/更新/删除操作。

如果我创建物化视图，我担心性能是否可以大大提高。因为来自其他表的数据变化非常频繁。很可能，每次选择视图之前都需要先创建视图。

有什么想法吗？例如如何缓存？我还能采取其他额外措施吗？

【问题讨论】：

您是否对表格进行了适当的索引？您是否分析过哪些查询很慢？索引可能是关于性能的最重要的事情。
是的，我有适当的索引。但我希望性能进一步提高。您的意思是，如果我有适当的索引，则不需要使用视图/额外的专用表来组合常用列？我认为将多个查询组合在一起可以节省查询性能。我只是不确定何时使用视图，何时为此创建额外的专用表
架构是什么？如何访问数据？

【解决方案1】：

如下所述，没有提高性能的灵丹妙药。而且，与上面所说的不同，索引不是对数据库性能最重要的事情 - 拥有正确设置的数据库才是。随着数据库变得更大，数据库配置可能会主导性能。其中最重要的是有一个适当配置的磁盘子系统，因为大型数据库的性能总是受到数据传输到磁盘或从磁盘传输的速度的限制。

至于您的具体问题，通过查询伪造具体化视图可能对您有帮助，也可能对您没有帮助。它可能会降低您的插入和更新性能，同时可能会提高您的选择性能。在需要时按需创建“视图”对您毫无用处，因为无论如何您都必须运行缓慢的查询来创建它。由于 MySQL 不直接支持物化视图，因此标准视图对您没有任何帮助。

如果没有更多细节，就不可能提供更好的帮助。

【讨论】：

【解决方案2】：

在我看来，您正在按照“materialized view”的概念进行思考。

Mysql 没有提供这个实现，虽然它可以用一些more 或less 复杂性来模拟（我在 Postgresql 中做了一些类似的事情 - 它对于经常使用的复杂的非参数化查询很方便在报告中，并且可以容忍没有完全最新的数据）。

【讨论】：

是的。我的意思是物化视图。我的数据总是最新的。我有通过 5-7 个表选择数据的非参数化查询。所以在我的情况下，创建物化视图和额外的表似乎都不是提高性能的可行选择？
物化视图总是可行的以获得更好的性能。但是，如果您确实需要严格的最新数据（即 mat.view 必须准确反映“真实”视图），您需要对触发器进行额外的工作，如我的第一个链接中所示。也许对您的数据库架构进行一些重新思考（甚至可能进行一些反规范化）可能会更可取。

【解决方案3】：

我正在考虑创建一个表或视图以从其他表中收集所有要求高的列，从而提高性能。
很可能，每次选择视图之前都需要先创建视图。

视图不过是查询。因此，无论您是进行查询以从视图中选择还是只执行普通 sql 都没有关系 - 性能将是相同的。

如何缓存

缓存是一个非常复杂和具体的问题。所以没有灵丹妙药，做决定时应该提供更多细节。

【讨论】：

所以如果我有比 CUD 更多的“选择”，那么创建一个新表更适合性能？否则，使用视图组合表格可以吗？
不。不知道如何在您的特定情况下提高性能，而我们不知道细节：存储的数据类型，查询类型（最多：插入/更新/删除/选择），选择类型（典型查询）、选择/修改比率、现在的行数、数据增长速度、当前和预期负载等
查询慢吗？如果是，是否已完全编入索引？