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

Question

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

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.16s持续时间。 当我使用使用相同查询创建的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

这很难准确 - 调查的最佳方法是在查询的两种风格上运行EXPLAIN 。

但是，我怀疑查询缓存是其核心 - 重新运行相同的查询将为查询缓存设定种子，除非底层数据发生更改，或者缓存被刷新，否则您可能会受益于缓存。

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

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