何时在MySQL中使用视图？

当通过多个联接创建表以用于分析时，何时使用视图而不是创建新表？

我更喜欢使用视图的原因之一是数据库模式是由我们的管理员从Ruby内部开发的，而我对Ruby并不熟悉。我可以要求创建表，但是需要额外的步骤，在开发/测试新联接时，我希望有更大的灵活性。

我开始在SO的一个相关问题（何时使用R，何时使用SQL）的答案之后使用视图。投票最多的答案开始为“在SQL中进行数据操作，直到数据在单个表中，然后在R中进行其余操作。”

我已经开始使用视图，但是遇到了一些视图问题：

1. 查询要慢得多
2. 视图不会从生产中转储到我用于分析的备份数据库中。

视图是否适合此用途？如果是这样，我应该期望性能下降吗？有没有一种方法可以加快视图查询？

MySQL中的视图使用两种不同算法之一处理：MERGE或TEMPTABLE。MERGE只是具有适当别名的查询扩展。TEMPTABLE听起来很像，视图在运行WHERE子句之前将结果放入临时表中，并且上面没有索引。

第三个选项是UNDEFINED，它告诉MySQL选择适当的算法。MySQL将尝试使用MERGE它，因为它效率更高。主要警告：

如果无法使用MERGE算法，则必须使用临时表。如果视图包含以下任何构造，则不能使用MERGE：

• 聚合函数（SUM（），MIN（），MAX（），COUNT（）等）

• 不同

• 通过...分组

• 拥有

• 限制

• UNION或UNION ALL

• 选择列表中的子查询

• 仅引用文字值（在这种情况下，没有基础表）

[src]

我敢冒险猜测您的VIEWS是否需要TEMPTABLE算法，从而导致性能问题。

这是一篇关于MySQL视图性能的非常古老的博客文章，而且似乎还没有变得更好。

但是，在此隧道的尽头可能会遇到一些不包含索引的临时表问题（导致全表扫描）。在5.6中：

对于FROM子句中的子查询要求实现的情况，优化器可以通过向实现的表添加索引来加快对结果的访问。...添加索引后，优化器可以将物化的派生表与具有索引的普通表相同，并且它从生成的索引中获得的好处也相似。与没有索引的查询执行成本相比，索引创建的开销可以忽略不计。

正如@ypercube指出的那样，MariaDB 5.3添加了相同的优化。本文对过程进行了有趣的概述：

应用优化后，派生表将无法合并到其父SELECT中，当派生表不符合可合并VIEW的条件时会发生这种情况

视图是安全工具。您不希望特定的用户或应用程序知道数据表在何处，而是只为视图提供所需的列。

请记住，视图总是会降低性能，类似的查询应该存储在过程和函数中，而不是视图。

要进行查询调优，请始终遵循最佳实践，避免使用WHERE子句中的函数，创建索引以加快选择速度，但不要滥用索引来降低插入，更新和删除的性能。

有很好的文档可以为您提供帮助：http : //www.toadworld.com/LinkClick.aspx?fileticket= 3qbwCnzY/ 0A=&tabid=234

我认为视图是用于将表合并为一个要从多表查询中克服的预定义结构（无数据），可以从实际数据中使用该结构来进行快速关系查询...