如果你走的是使用视图的道路，你如何确保良好的性能？
还是最好不要一开始就使用视图，而只是将等效的内容合并到您的选择语句中？
问问题
100134 次
6 回答
122
这取决于。
这完全取决于您通过视图查看的内容。但很可能会减少您的工作量并提供更高的性能。当 SQL 语句引用非索引视图时，解析器和查询优化器分析 SQL 语句和视图的来源，然后将它们解析为单个执行计划。SQL 语句没有一个计划，视图也没有一个单独的计划。
未编译视图。它是由其他表组成的虚拟表。当您创建它时，它并不驻留在您的服务器上的某个位置。构成视图的底层查询受到查询优化器相同的性能增益或叮当声的影响。我从未测试过视图 VS 其底层查询的性能，但我想性能可能会略有不同。如果数据相对静态，您可以在索引视图上获得更好的性能。这可能是您在“编译”方面的想法。
视图的优点：
- 查看数据而不将数据存储到对象中。
- 限制表的视图，即可以隐藏表中的某些列。
- 连接两个或多个表并将其作为一个对象显示给用户。
- 限制对表的访问，使任何人都不能将行插入到表中。
查看这些有用的链接：
于 2012-04-30T07:15:28.367 回答
13
这是一个 tl;dr 摘要，您可以从 Peter Zaitsev 和其他地方找到详细的评估。
MySQL 中的视图通常是个坏主意。在 Grooveshark，我们认为它们是有害的，并始终避免使用它们。如果你小心，你可以让它们工作，但充其量它们是一种记住如何选择数据或让你不必重新输入复杂连接的方法。在最坏的情况下，它们会导致大量的低效率、隐藏复杂性、导致意外的嵌套子选择（需要临时表并导致磁盘抖动）等。
最好避免它们，并将您的查询保留在代码中。
于 2012-04-28T05:48:30.187 回答
11
我认为 Peter Zaitsev 的博客包含了大部分细节。如果您通常保持简单，那么从个人经验来看，它们的效果会很好。在我的一个客户中，他们不断地将一个视图叠加在另一个视图之上，结果却是一场性能噩梦。
通常我使用视图来显示表格的不同方面。例如，在我的员工表中向我显示经理或对非 HR 员工隐藏薪水字段。还要始终确保在查询和视图上运行 EXPLAIN 以准确了解 MySQL 内部发生的情况。
如果您想在您的场景中获得可靠的证据，我建议您进行测试。真的很难说使用视图总是一个性能杀手，那么糟糕的视图可能会扼杀你的性能。
于 2012-04-27T07:56:19.740 回答
8
它们服务于它们的目的，但隐藏的复杂性和低效率通常超过更直接的方法。我曾经遇到一个 SQL 语句，它连接两个视图，并对结果进行排序。视图也在排序，所以执行时间可以用几小时来衡量。
于 2012-04-28T16:45:06.497 回答
6
到目前为止没有提到但产生巨大差异的事情是视图源表的充分索引。
如上所述，视图并不驻留在您的数据库中，而是每次都重新构建。因此，使数据库的重建更容易的一切都会提高视图的性能。
通常，视图连接数据的方式对存储非常不利（非正常形式），但对进一步使用（进行分析、向用户呈现数据……）非常有利，从而连接和聚合来自不同表的数据。
进行操作的列是否被索引对视图的性能有很大的影响。如果表及其相关列已被索引，则访问视图不会以一遍又一遍地重新计算索引而告终。（不利的一面是，这是在源表中操作数据时完成的）
！索引 CREATE VIEW 语句中 JOINS 和 GROUP BY 子句中使用的所有列！
于 2014-12-05T12:49:16.120 回答
3
如果我们讨论的是“如果你使用视图，如何确保性能”，而不是一般视图的性能效果，我认为它归结为克制（就像你自己一样）。
如果您只是编写视图以使您的查询在所有情况下都很简单，那么您可能会遇到大麻烦，但不要注意您的视图实际上在性能方面很有用。您最终所做的任何查询都应该运行正常（请参阅@eggyal 链接中的评论示例）。当然，这是一个重言式，但因此没有任何价值
您尤其需要小心不要从视图中创建视图，因为这可能会使创建该视图更容易。
最后，您需要查看使用视图的原因。每当您这样做以使编程端的生活更轻松时，恕我直言，您可能会更好地使用存储过程。
为了控制事情，你可能想写下为什么你有一个特定的观点，并决定你为什么使用它。对于您的编程中的每一个“新”用途，重新检查您是否真的需要该视图，为什么需要它，以及这是否仍然会给您一个合理的执行路径。继续检查您的用途以保持速度，并继续检查您是否真的需要该视图。
于 2012-04-27T08:00:44.160 回答