2010-05-24 36 views
2

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

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

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

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

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

+0

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

+0

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

+0

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

回答

0

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

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

+0

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

+0

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

2

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

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

如何緩存

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

+0

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

+0

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

+0

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

0

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

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

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

相關問題