MySQL视图的性能比底层查询的性能差[重复]答案

【问题标题】：Performance of MySQL View is Worse than that of Underlying Query [duplicate]MySQL视图的性能比底层查询的性能差[重复]
【发布时间】：2013-03-30 18:13:57
【问题描述】：

我有一个使用下面定义的 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 内联。

【问题讨论】：

这个问题可以和这个link相关！
还有这个。 . . mysqlperformanceblog.com/2007/08/12/….
@pallav_rus 感谢您的链接，但它似乎解决了视图如何比其基础查询具有更好的性能。此外，它适用于带有索引视图的 SQL Server。我不相信 MySQL 中提供了索引视图，但很想知道它们是可用的。
@GordonLinoff 感谢您的链接。它看起来更接近问题。这可能是由于我的经验不足，但它似乎没有解决我遇到的问题，即视图比其确切的底层查询慢。相反，它似乎与在添加 WHERE 子句而不是使用具有相同 WHERE 子句的基础查询时可能出现 JOIN'ing 视图或 SELECT'ing FROM a VIEW 效率低下的问题有关。
@Jobu：如果可以的话，试试MariaDB（一个 MySQL 的替代品），它对 Views 的优化器有一些改进。

标签： mysql performance view

【解决方案1】：

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

在我的查询中使用 SELECT DISTINCT 对 726,000 行表和 303,000 行表执行 INNER JOIN，加入每个表具有索引的 3 列，直接查询运行大约 0.15-0.16 秒的持续时间。当我使用使用相同查询（仅此而已）创建的 VIEW 时，持续时间约为 142-145 秒或大约 10^3 倍。

删除 DISTINCT 将查询本身和它所基于的视图都减少到 0.016 秒——几乎没有任何区别。

我无法理解为什么——只有在一个特定情况下识别出一个原因。

【讨论】：

【解决方案2】：

我不确定，但也许 mysql 对其中一个查询使用 tmp 表要好得多。请调整这些设置，然后重试：

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

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

【讨论】：

【解决方案3】：

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

但是，我怀疑query cache 是其中的核心 - 重新运行相同的查询将为查询缓存提供种子，除非基础数据更改或缓存被刷新，否则您可能会从缓存中受益。

您也希望在访问视图时也能获得这种好处，但缓存是不确定的，我的猜测是，不知何故，您对视图的查询并没有从缓存中受益。

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

【讨论】：

MySQL 查询缓存在该系统上被禁用。正如使用#ypercube 进行调试所显示的那样，它不是由派生表的存在驱动的。但我确实认为我从EXPLAIN 语句中得到了一些东西，这些语句显示了查询中的某些内容，当通过视图访问数据时，这些内容无法被优化掉。