我有一個複雜的查詢使用很多連接(實際上是8)。我正在考慮將它簡化成一個視圖。經過一些研究,我可以看到簡單性和安全性的好處。但我沒有看到任何速度的提及。MySQL視圖比普通查詢更快嗎?
視圖是否像預編譯語句一樣工作,其中查詢是預編譯的?使用視圖有什麼顯着的性能收益?
我有一個複雜的查詢使用很多連接(實際上是8)。我正在考慮將它簡化成一個視圖。經過一些研究,我可以看到簡單性和安全性的好處。但我沒有看到任何速度的提及。MySQL視圖比普通查詢更快嗎?
視圖是否像預編譯語句一樣工作,其中查詢是預編譯的?使用視圖有什麼顯着的性能收益?
不,視圖只是一個存儲的文本查詢。您可以對其應用WHERE
和ORDER
,執行計劃將根據這些條款進行計算。
這不完全正確。如果您爲視圖算法選擇合併,這基本上是正確的,但是如果您選擇了可修改,它將會實現。未定義(默認情況下,如果未指定)讓MySQL選擇,這可以做你可能不期望的事情。 – Ray 2011-01-25 02:18:31
我不是MySQL的專家,但我很確定TempTable算法控制MySQL在處理請求結果時如何處理視圖,並且完全不影響視圖的存儲方式。 – 2011-01-25 02:38:37
它有時可以幫助,但它不是銀彈。我已經看到了觀看幫助表演,但我也看到它傷害了它。一個視圖可以強制實現,如果MySQL沒有爲你選擇一個好的視圖,有時可以讓你獲得更好的訪問路徑。
一個視圖的基本上存儲的子查詢。有本質上沒有區別:除視圖
SELECT *
FROM someview
和
SELECT *
FROM (
SELECT somestuff
FROM underlying table
);
更輕便一點,因爲你沒有給你想要的任何數據去上班時間寫出來的基礎查詢它返回。
有些數據庫會預編譯視圖,但我不相信MySQL會。你可能想看看這個問題:http://stackoverflow.com/questions/1021319/how-to-optimize-mysql-views – 2011-01-25 02:17:30
與答案相反 - 根據我的經驗,對於有很多連接的視圖,直接做查詢運行得更快。 – 2015-11-20 17:23:28