快取的話 根據你的業務來設計好了

nosql 寫udf 庫內計算。。

效率高，不佔什麼地方。

如果讓我寫，我可能會這樣，可能有更好的辦法。

簡單總結如下：

一 分割思想：

1 資料庫切分：使用者庫、主題庫、回覆庫

2 資料表水平切分：使用者庫1-n、主題庫1-n、回覆庫1-n （比如按時間分）

3 分散式資料庫：每臺計算機中都有DBMS的一份完整複製副本，並具有自己區域性的資料庫，位於不同地點的許多計算機透過網路互相連線，共同組成一個完整的、全域性的大型資料庫。

4 論壇功能可以進行分隔，不同的伺服器負責不同的功能

5 用主從資料庫，master是寫， slave是讀

6 把內容與其它資訊分開，好處就是可以讓每個表的檔案最小化,對資料庫操作壓力會減小，這樣保證每張表資料量很小，操作速度會快，也可以在這裡使用快取

二 索引：

針對是否建立索引有著一定的分歧：

我覺得建立索引還是很有必要的。理由如下：

1）建立索引可以加快檢索速度，對於論壇讀和寫的比例相差很大，使用者體驗當然是讀多寫少，所以綜合考慮還是要用索引，而且是加在常用的讀關鍵字上。

2）索引之所以會降低更新的速度，是因為更新還包括對索引的更新，從更新帖子10萬左右，這句話是說，我們可能對發帖標題，發帖內容，回覆標題，回覆內容這4個欄位做更新。需要注意的是，這四個欄位並不是用來建立表連線的欄位，為了最佳化查詢速度我們不會在這四個欄位上建立索引，所以從這道題目出發，我們建立的索引不會影響更新帖子的效能。只要被索引的列（例如回覆表的標題ID）不被頻繁更新,即使索引所在地行的其它列被頻繁update,索引也不會被更新從而產生效能消耗,一張表一天30萬次的索引更新,因它引起的效能消耗小到即使資料庫安裝在奔騰3單核CPU下都能輕鬆承擔下來。

3）對於更新的速度慢的問題，我們有解決的方法，你提交更新了後，前臺可以讓程式返回一個正確結果，後臺開個執行緒非同步慢慢跟新資料庫就是了，反正更新成功的前提就是假設資料庫連線永遠正確並處於可靠狀態。在資料庫和使用者之間建立一個緩衝區。(如，將更新的資料放到記憶體中，達到一定數量的時候再統一更新資料庫。假如以100條為例，一旦記憶體中達到100條資料量將這100條資料統一入庫。減少insert操作)

三 緩衝：

讀的時候的緩衝：快取路由表

主題快取表（這個取每個區的前面100條記錄），一般來說負載最大的就是主題的第一頁，所以快取表是個小表。

另外使用hibernate，在資料庫上面加了一層快取。

生成靜態頁，快取最熱，最新的帖子。

對於經常更新的資料都設計成單獨表 ，這樣可以最大程度的利用hibernate快取

避免記憶體過大，每次使用者看帖的時候，首先檢索快取中時候有需要的帖子，沒有的話再訪問資料庫，然後將資料庫返回的帖子資訊儲存到快取中。

寫的時候的緩衝：資料庫和使用者之間建立快取，將更新的資料放在記憶體中，非同步操作的。所有的寫貼操作 放到一個佇列然後批次執行插入資料庫操作。

預估計的緩衝：假如使用者第一次開啟某標題，那將此標題的相關的前100條資料快取到客戶斷。這樣避開對資料庫的直接查詢，減少資料庫壓力。

四 程式碼最佳化

1儘量避免表的連線約束透過程式碼來實現約束 例如使用者id的驗證在使用者登入時驗證這樣就可以把帖子表的使用者id外來鍵去掉這樣就成了單表操作、查詢 而連線可以透過觸發來實現這樣最多是查詢了3個表而不是連線中的笛卡爾笛卡爾積 回覆表的查詢限定每次查詢的記錄數例如限定10條其它的透過點選觸發來操作"注程式碼最佳化容易出現bug 原因有些開發工具本身有最佳化"

五 資料庫效能調優

儘量用硬體來代替軟體最佳化 原則就是能用硬體的儘量用硬體 比如磁碟陣列 RAID0 有條件用RAID10 加大記憶體 .避免小表上建索引 對論壇來說資料帖子和回覆不是很重要 可以定期刪除一些垃圾帖子 樓主說的幾百萬條記錄的論壇對現在的資料庫管理系統和計算機來說永不著刻意的最佳化,定期維護打包備份資料庫就可以了

提高速度的關鍵:

1.建立合理的索引並在查詢時充分利用;

2.避免使用關聯,這樣避免整表掃描;使用關聯不如多次使用主鍵查詢來的快;

3.一些處理的功能儘可能放到記憶體中來做,比如組織主題和回覆;

4.海量快取（使用靜態頁面也是個不錯的做法）

5 定期對錶進行轉儲