1

我想知道是否有人对拥有视图的性能与删除数据并插入临时表的脚本有很好的统计。

所以，作为一个非常简单的例子，如果我们有一张全国商店的表格，我们想要加利福尼亚的所有商店。我本能地知道视图是实现这一目标的最佳方式。但是，我对 MySQL 的了解还不够充分，无法 100% 肯定地说视图比截断表并插入来自加利福尼亚的所有经销商的脚本要好得多。我提出它的原因是，在某些（更复杂的）情况下，执行此操作的脚本有时比从视图中选择要快。

所以，我要问的基本上是创建表和填充它的开销是否比只在 MySQL 中创建视图更可取。

4

2 回答 2

2

MySQL 中的视图可能很棘手。例如，它们不支持from子句中的子查询。

对于大多数数据库，我会提倡使用视图。使用 MySQL，情况有点棘手，因为您可能无法轻松地将所需的查询表达为视图。

使用临时表有一定的优势。您可以为给定的查询添加适当的索引。表的大小很好理解（如果你碰巧有一个基于统计的查询优化器）。在某些环境中，临时数据库可能位于比原始数据更快的磁盘上。而且，临时表可能适合原始表不适合的内存。这可能会对更新产生巨大影响。

因此，您可以尝试查看它是否适用于您的情况。由于视图的限制，它不一定涵盖所有情况。而且，临时表很有可能实际上会表现得更好。

于 2013-06-06T16:05:04.413 回答
1

您的措辞建议您考虑在每次需要“加利福尼亚商店”列表时从表中提取行子集（例如）stores并将其复制到表中（例如）（例如）的选项。此选项可能比视图更昂贵，而且充其量是无用的。storesInCalifornia

我写了“可能更昂贵”，因为实际上有可能在从视图中读取时（或者更确切地说，在将视图中的记录与其他表或视图组合时），内部会创建一个临时表（参见TEMPTABLEalgorithm）。

我想您宁愿考虑storesInCalifornia每次都不会重建的配置。一个触发器stores可以使两者同步。

这个解决方案可能更可取，我想它会比在常规表上读取的视图执行得更好（主要原因是表中的行较少，因此索引更小，等等）。现在您仍然需要确定这种收益是否值得对更新产生负面影响。这取决于您的应用程序使用情况，并且没有正确答案。

现在有一个结合了两全其美的解决方案。分区。stores您可以按州和/或国家/地区进行分区，并在其上创建一个视图。唯一的缺点（但主要的一个）：分区不支持外键。

于 2013-06-06T16:05:46.857 回答