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相同，那將是最好的解釋......