哪個更好，創建物化視圖還是新表？

我有一些要求 mysql查詢必須選擇相同經常更新的數據集從5-7 mysql表。 '選擇'操作將比CUD多一點。哪個更好，創建物化視圖還是新表？

我想創建一個表或物化視圖來收集來自其他表的所有要求的列，以便將整個查詢時間減少到不同的表，從而提高性能。

如果我創建了該表，那麼每次更新其他表時，可能需要執行額外的插入/更新/刪除操作。

如果我創建物化視圖，我擔心如果性能可以大大提高。因爲來自其他表格的數據變化非常頻繁。很可能，在選擇視圖之前，可能需要首先創建視圖。

任何想法？例如如何緩存？我可以做的其他額外措施？

2010-05-24 Capitaine

您是否適當地爲表格編制索引？你有沒有分析查看哪些查詢速度慢？索引可能是關於性能的最重要的事情。 – 2010-05-24 23:57:05

是的，我有適當的索引。但我希望表現會更好。你的意思是，如果我有適當的索引，不需要使用視圖/額外的專用表來組合常用的列。我認爲將mutilple查詢合併爲一個可以節省查詢性能。我只是不確定什麼時候使用視圖，什麼時候創建一個額外的專用表 – Capitaine 2010-05-25 00:25:33

什麼是模式？數據如何被訪問？ – 2010-05-25 01:15:01

在我看來，你正在考慮沿着「materialized view」概念的思路。

MySQL沒有提供這方面的一個實現，雖然它可以與一些more或less複雜模擬（我做類似的PostgreSQL後來的東西 - 它的方便了那些經常在報告中使用複雜的非參數化查詢，並且可以容忍不完全最新的數據）。

來源

2010-05-25 00:45:36 leonbloy

是的。我的意思是物化視圖。我的數據總是最新的。我有通過5-7表選擇數據的非參數化查詢。所以在我的情況下，創建物化視圖和額外的表格似乎都不是提高性能的可行方案？ – Capitaine 2010-05-25 01:00:27

物化視圖總是可行的，以獲得更好的性能。但是，如果您真的需要嚴格的最新數據（即mat。view必須完全反映「true」視圖），那麼您需要使用觸發器做額外的工作，就像我的第一個鏈接一樣。也許一些你的數據庫模式的重新思考（也許甚至一些反規範化）可能更可取。 – leonbloy 2010-05-25 01:45:11

我想創建一個表或視圖來收集其他表中所有要求很高的列，以提高性能。
很可能，在選擇視圖之前，可能需要每次創建視圖。

視圖只是查詢。因此，無論您是使用查詢來從視圖中選擇還是僅執行普通的sql，性能都將保持不變。

如何緩存

緩存是非常複雜的，具體的問題。所以沒有靈丹妙藥，要做出決定，應該提供更多細節。

來源

2010-05-24 23:56:55 zerkms

因此，如果我比CUD有更多'選擇'，那麼創建一個新表更適合於性能？否則，使用視圖來組合表是好的？ – Capitaine 2010-05-25 00:21:25

nope。我們不知道如何提高你的特定情況下的性能，而我們不知道細節：存儲的是什麼類型的數據，查詢的類型（最多的是：插入/更新/刪除/選擇），選擇的類型典型查詢），選擇/修改比率，現在行數，數據增長速度，當前和預期負載等等。 – zerkms 2010-05-25 00:45:53

查詢速度是否慢？如果是這樣，它是否完全索引？ – 2010-05-25 12:05:15

如下所述，增加性能沒有靈丹妙藥。而且，與上述內容不同的是，索引是而不是對於數據庫性能最重要的事情 - 擁有正確設置的數據庫。隨着數據庫變大，數據庫配置可能會成爲性能的主導。其中最重要的是擁有適當配置的磁盤子系統，因爲大型數據庫的性能始終受限於數據傳輸到磁盤的速度有多快。

至於您的具體問題，通過查詢僞造物化視圖可能會幫助您，也可能不會幫助您。這可能會降低您的插入和更新性能，同時可能會提高您的選擇性能。在需要時根據需要創建「視圖」對你來說毫無用處，因爲你必須運行緩慢的查詢來創建它。由於MySQL不直接支持實現視圖，因此標準視圖對您無能爲力。

沒有更多的細節更好的幫助是不可能的。

來源

2010-05-25 01:11:29 Donnie

哪個更好，創建物化視圖還是新表？

回答

相關問題