如果您打算使用视图，那么如何确保良好的性能？

还是最好不要先使用视图，而只是将等效视图合并到您的select语句中？

这取决于。

这完全取决于您通过视图查看的内容。但最有可能减少您的精力并提供更高的性能。当SQL语句引用非索引视图时，解析器和查询优化器将分析SQL语句和视图的源，然后将它们解析为一个执行计划。SQL语句没有一个计划，而视图则没有一个单独的计划。

视图未编译。它是由其他表组成的虚拟表。创建它时，它不会驻留在服务器上的某个位置。组成该视图的基础查询要经受与查询优化器相同的性能提升或影响。我从未在视图VS底层查询上测试过性能，但是我想性能可能会略有不同。如果数据是相对静态的，则可以在索引视图上获得更好的性能。这可能就是您在“编译”方面的想法。

视图的优点：

1. 查看数据而不将数据存储到对象中。
2. 限制表的视图，即可以隐藏表中的某些列。
3. 连接两个或多个表并将其作为一个对象显示给用户。
4. 限制对表的访问，以便没有人可以将行插入表中。

请参阅以下有用链接：

1. VIEW与SQL语句的性能
2. 视图比简单查询快吗？
3. MySQL VIEWS与PHP查询
4. MySql视图动态且高效吗？
5. 物化视图与表格：有哪些优点？
6. 通过视图查询是否比直接执行SQL慢？
7. TEMPTABLE视图性能问题的解决方法
8. 通过在SQL Server中使用索引视图查看性能提升

我认为Peter Zaitsev的博客提供了大部分详细信息。如果您通常将其简单化，那么从个人经验观点进行的发言可以取得良好的效果。在我的一位客户中，他们不断地将一个视图叠加在另一个视图上，结果陷入了一场梦night以求的梦m。

通常，我使用视图来显示表的不同方面。例如，在“我的员工”表中，向我显示经理或对非HR员工隐藏薪水字段。还要始终确保对查询运行EXPLAIN并查看以确切了解MySQL内部正在发生的事情。

如果您想在场景中提供可靠的证据，我建议您进行测试。很难说使用视图始终是性能的杀手，然后，写得不好的视图很可能会破坏性能。

这是tl; dr的摘要，您可以从Peter Zaitsev和其他地方找到详细的评估。

MySQL中的视图通常不是一个好主意。在Grooveshark，我们认为它们有害，并始终避免使用它们。如果您很谨慎，则可以使它们起作用，但充其量是一种记住如何选择数据或使您不必重新键入复杂联接的方法。在最坏的情况下，它们可能导致大量的低效率，隐藏复杂性，导致意外的嵌套子选择（需要临时表并导致磁盘崩溃）等。

最好只是避免它们，并将查询保留在代码中。

它们达到了目的，但是隐藏的复杂性和效率低下通常比直接方法更为重要。我曾经遇到一个SQL语句，该语句在两个视图上进行联接，并对结果进行排序。视图也在排序，因此执行时间可以用几小时来衡量。

到目前为止尚未提及但有很大不同的是对视图的源表进行适当的索引编制。

如上所述，视图并不驻留在您的数据库中，而是每次都会重新构建。因此，使数据库重建更容易的所有方面都会提高视图的性能。

通常，视图以对存储非常不利（没有标准格式）但对进一步使用（进行分析，向用户呈现数据等）非常有利的方式联接数据，并因此联接和聚合来自不同表的数据。

是否对在其上进行操作的列建立索引，对视图的性能产生巨大的影响。如果已对表及其相关列进行了索引，则访问该视图不会导致首先一次又一次地重新计算索引。（不利的是，这是在源表中处理数据时完成的）

！为您的CREATE VIEW语句中的JOINS和GROUP BY子句中使用的所有列编制索引！

如果我们讨论的是“如果您使用视图，如何确保性能”，而不是讨论视图的总体效果，那么我认为它归结为束缚（就像您自己一样）。

如果您只是编写视图以使查询在所有情况下都变得简单，那么您可能会遇到麻烦，但不要担心视图实际上在性能方面是有用的。最后，您正在执行的任何查询都应该运行正常（请参阅@eggyal链接中的注释示例）。当然这是一个重言式，但因此价值不菲

您尤其需要谨慎，不要仅从视图中创建视图，仅因为这样做可能会使创建该视图更容易。

最后，您需要查看使用视图的原因。任何时候这样做都可以简化编程端的工作，使用存储过程恕我直言可能会更好。

为了控制一切，您可能需要写下为什么拥有某种视图，并决定为什么要使用它。对于编程中的每个“新”用途，请重新检查您是否确实需要视图，为什么需要它，以及是否仍然可以使用一个合理的执行路径。继续检查您的使用以使其保持快速运行，并继续检查是否确实需要该视图。