MySql查看性能

Question

如果您正在使用视图,那么如何确保良好的性能？

或者最好不要首先使用视图,只是将等效语句合并到select语句中？

Answer 1

这取决于.

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

视图未编译.它是由其他表组成的虚拟表.创建它时,它不会驻留在服务器上的某个位置.构成视图的基础查询受查询优化器的相同性能提升或约束.我从来没有在视图VS的基础查询上测试性能,但我认为性能可能略有不同.如果数据相对静态,则可以在索引视图上获得更好的性能.这可能就是你所想的"编译".

目前没有MySQL不支持索引视图. (4认同)
您提到了索引视图，并且您有多个索引和物化视图文章的链接。这一切都很好。但是 MySQL 有索引视图吗？ (2认同)
好答案.我将添加一个视图基本上是MySQL中的命名查询.如果确保生成视图的查询在单独运行时具有良好性能,则视图应执行类似操作. (2认同)
额外的 ~~ 视图优势可以与限制访问相反 - 当您设置视图权限时，您实际上可以“添加/更新/删除”数据以将其视为真实表进行查看（导致部分查询将改变真实表) (2认同)
“我从未测试过视图 VS 其底层查询的性能，但我认为性能可能会略有不同。” - 遗憾的是，对于 MySQL，“略有不同”是一种严重的轻描淡写。视图可能比直接执行 SELECT 语句慢几个数量级。 (2认同)

Answer 2

我认为Peter Zaitsev的博客有大部分细节.从个人经验来看,如果你通常保持简单,那么观点可以很好.在我的一个客户面前,他们不断将一个视图叠加在另一个视图之上,最终导致了一场性能噩梦.

通常我使用视图来显示表的不同方面.例如,在我的员工表中,向我显示经理或隐藏非HR员工的薪资字段.还要始终确保在查询和视图上运行EXPLAIN以准确了解MySQL内部发生的情况.

如果你想在你的场景中得到可靠的证据,我会建议你进行测试.很难说使用视图始终是一个性能杀手,然后再写一个写得不好的视图可能会破坏你的表现.

Answer 3

这是一个tl; dr摘要,你可以找到Peter Zaitsev和其他地方的详细评估.

MySQL中的视图通常是一个坏主意.在Grooveshark,我们认为它们是有害的并且总是避免它们.如果你小心,你可以使它们工作,但最好的方法是记住如何选择数据或让你不必重新输入复杂的连接.在最坏的情况下,它们可能导致大量低效,隐藏复杂性,导致意外嵌套的子选择(需要临时表并导致磁盘抖动)等.

最好避免使用它们,并将查询保存在代码中.

Answer 4

它们服务于他们的目的,但隐藏的复杂性和低效率通常超过更直接的方法.我曾经遇到过一个加入两个视图的SQL语句,并对结果进行排序.视图也在排序,因此执行时间可以在几个小时内测量.

Answer 5

到目前为止还没有提到但产生巨大差异的一件事是对视图的源表进行足够的索引。

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

通常，视图以一种非常不利于存储的方式连接数据（非标准形式），但非常适合进一步使用（进行分析，向用户呈现数据，...），从而连接和聚合来自不同表的数据。

进行操作的列是否被索引对视图的性能有巨大的影响。如果表及其相关列已被索引，则访问视图不会首先一遍又一遍地重新计算索引。（不利的一面是，这是在源表中操作数据时完成的）

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