我應該使用CREATE VIEW，而不是全部加入時間

我有以下查詢：我應該使用CREATE VIEW，而不是全部加入時間

SELECT t.*, a.hits AS ahits 
       FROM t, a 
       WHERE (t.TRACK LIKE 'xxx') 
       AND a.A_ID = t.A_ID 
       ORDER BY t.hits DESC, a.hits DESC

它運行非常頻繁。表t有大約15M +行，a有大約3M +行。

當我在上面的查詢上做了EXPLAIN時，我收到一條消息說它總是創建一個臨時表。我注意到基於上述查詢創建臨時表需要相當長的一段時間。而且，這樣做很多時間。

因此，我想知道如果我使用上面創建一個視圖說：

CREATE VIEW v_t_a 
SELECT t.*, a.hits AS ahits 
FROM t, a 
WHERE a.A_ID = t.A_ID

而且我的代碼更改爲：

SELECT * FROM v_t_a WHERE TRACK LIKE 'xxx' ORDER BY hits DESC, ahits DESC

它會提高性能？它會刪除創建臨時表時間嗎？

非常感謝您的建議！

來源

2012-03-06 Heru S

查看內部加入兩個表您每次查詢視圖...！

爲了防止這種情況，創建MATERIALIZED VIEW ...

It is a view that is more of a TABLE ...You can query it directly as other table..

但是你必須寫一些觸發器來自動更新它，如果任何基礎表數據的變化......

看到這個：http://tech.jonathangardner.net/wiki/PostgreSQL/Materialized_Views

來源

2012-03-06 06:08:18

感謝您對Ramandeep的意見。 – 2012-03-12 07:37:53

隨時.. !!! :) – 2012-03-12 08:10:02

在視圖中執行完全相同的操作將比查詢更有效。

視圖更多的是管理查詢的複雜性而不是性能，它們只是在後端執行與查詢相同的操作。

對此的一個例外是物化查詢表，它實際上爲查詢創建單獨的長效表，以便後續查詢更高效。我不知道MySQL是否有這樣的事情，我自己是DB2的人:-)

但是，如果查詢的性能是一個問題，您可能自己實現這樣的方案。

它很大程度上取決於表格的變化率。如果數據變化頻繁，以至於每次都必須重新生成具體化的查詢，那麼這將不值得。

來源

2012-03-06 06:06:49 paxdiablo

如果您認爲MySQL會像更先進的數據庫系統一樣優化您的VIEW，這是非常危險的。與子查詢和派生表相同MySQL 5.0將失敗並且執行效率非常低。 MySQL有兩種處理VIEWS的方法 - 查詢合併，在這種情況下，VIEW被簡單地擴展爲宏或臨時表，在這種情況下，VIEW被實現爲臨時表（沒有索引！），後者在查詢中進一步使用執行。似乎沒有任何優化應用於用於從外部查詢創建臨時表的查詢，而且如果您使用了多個臨時表視圖並將它們連接在一起，那麼您可能會遇到嚴重問題，因爲這些表不會獲得任何索引。

因此，要非常小心地在您的應用程序中實現MySQL VIEWs，特別是那些需要臨時表執行方法的應用程序。視圖可以用於非常小的性能開銷，但只有在謹慎使用的情況下。

MySQL有很長的路要走正確優化VIEW查詢。

來源

2012-03-06 06:13:22

我應該使用CREATE VIEW，而不是全部加入時間

回答

相關問題