大表上的MySQL性能問題 - 如何有效地緩存結果？

我有一個MySQL表，用於存儲具有> 2MM行和8列以及userID上的索引的用戶統計信息。當用戶訪問他的個人資料時，會從數據庫中檢索出大量信息，最糟糕的情況是，幾十個SELECT查詢有時會與其他表格一起加入。它與SO上的配置文件類似，它也需要大量的數據。大表上的MySQL性能問題 - 如何有效地緩存結果？

一些想要獲得用戶分數的查詢需要COUNT和其他性能，吃掉MySQL函數。所以只需查看配置文件頁面可能需要10-20秒。

現在我的問題：

如何像這樣一個網站，拉這麼多的信息，迅速？
我需要一個緩存層嗎？
我是否應該預先計算出消耗MySQL性能的分數等的計數值？
我應該使用一個寫入優化表和一個讀取優化表嗎？如果是這樣，我可以如何檢索SO上的實時數據？
我應該離開MySQL嗎？

來源

2012-07-17 Horen

如何像這樣一個網站，拉這麼多的信息，迅速？

他們給你拔「這麼多的」數據幻覺，但在現實中，他們獲得一次一個塊。基本上，您需要一個查詢來獲得結果的COUNT，另一個查詢可以獲取該結果集中任何頁面的數據。結果集不被緩存。查詢的參數可以被緩存。但最好以每個頁面請求提供查詢參數的方式來實現。

我需要一個緩存層嗎？

可能是。但沒有必要執行此操作。緩存對於存儲先前提取的頁面可能很有用，並且整個社區使用相同的頁面，而不是一個用戶。

我應該預先計算消耗MySQL性能的分數等嗎？

與此用例無關。

我應該使用一個寫入優化表和一個讀取優化表嗎？如果是這樣，我怎麼能像SO上檢索實時數據？

不需要。

我應該離開MySQL嗎？

不需要。

有關此概念的更多詳細信息，請查閱分頁的Ajax網格

來源

2012-07-17 21:37:52

這是一個很好的答案。總結一下，我應該減少查詢的數量，並在需要時提取信息 - 因此基於事件。然而，問題是在像名人堂這樣的一些頁面上，我需要很多關於很多用戶的信息。所以我不能輕易減少查詢次數。那麼下一步應該是什麼？ – Horen 2012-07-17 22:06:44

對於有很多業務規則的密集查詢，最好是定期離線計算這些視圖，並將它們物化（臨時表），並將它們用作快速訪問數據。緩存聽起來很棒，實際上很容易實現，直到解決緩存失效的問題。數據背後的業務規則越多，執行失效就越困難。所以數據的週期性實現更容易實現。 – 2012-07-18 12:47:33

所以你的意思是我應該創建臨時表，只包含例如計算用戶得分，因爲計算需要大部分時間，臨時表上的「select」會非常快，對嗎？有一個缺點，數據不會生活，只是不時計算 - 哪種吸引... – Horen 2012-07-18 16:22:57

大表上的MySQL性能問題 - 如何有效地緩存結果？

回答

相關問題