MySQL View的性能比底层查询的性能差

Question

我使用下面的（为了简洁省略了JOIN语句）定义了MySQL视图。

CREATE VIEW vw_example AS 
SELECT a, b, c FROM x, y, z

多次重复SELECT a, b, c FROM x, y, z比SELECT a, b, c FROM vw_example快5倍。

我希望了解这是为什么以及如何将SELECT FROM vw_example效果与基础SELECT FROM x, y, z内联。

Answer 1

虽然您没有在示例查询中显示DISTINCT，但我最近发现这是直接查询运行与作为视图运行之间性能差异的唯一区别因素。

在我的查询上使用SELECT DISTINCT对726,000行表和303,000行表进行INNER JOIN，连接ON 3列，每个表都有一个索引，直接查询运行时间约为0.15-0.16秒。当我使用使用相同查询创建的VIEW（没有别的）时，持续时间大约为142-145s或大约10 ^ 3倍。

删除DISTINCT减少了查询本身及其基于0.016秒的视图 - 实际上几乎没有任何区别。

我无法理解为什么 - 只有在一个特定情况下认识到一个原因。

Answer 2

我不确定，但是对于其中一个查询，mysql可能更好地使用tmp表。请调整这些设置，然后重试：

tmp_table_size   100M
max_heap_table_size 128M
query_cache_limit  350M
query_cache_size 300M

在他们面前使用set global，以便您可以动态设置它们，希望这可能会起作用。如果没有，那么您可能需要重新编写查询。

Answer 3

很难准确 - 最好的调查方法是run EXPLAIN on both flavours of the query。

然而，我怀疑query cache是其中的核心 - 重新运行相同的查询将为查询缓存设定种子，除非底层数据发生变化，否则缓存会被刷新，你就是可能会从缓存中受益。

你也期望在点击视图时获得这样的好处，但是缓存是非确定性的，我的猜测是，不管怎样，你对视图的查询都没有从缓存中受益。

如果EXPLAINs相同，那将是最好的解释......