1）數據分表存儲 減輕數據單表壓力

自織夢V5版本起，DedeCMS開始分表存儲以提高系統負載性能，確實在一定程度上緩解了數據壓力?，F在最新的DedeCMS V5.7版本已經出來了，據官方介紹，V5.7調整了緩存處理，應付50萬以內數據沒問題，至于真實性無從考究。如果官方陳述屬實的話，對于中小型站長來說確實是件好事，正常百萬級內數據也不用過多擔心了。

分表存儲如何操作？

如果你只是個人或企業等小型站點，數據量也就撐死上萬，那完全不用考慮分表存儲，DedeCMS完全可以勝任。分表操作很簡單，你只需要直接進入后臺，新建模型，然后設置一個欄目對應一個模型。個人建議一個大的頻道欄目及子欄目對應一個模型，這要根據你的欄目可能存儲的數據來做計劃，考慮實際一點的分表方案。

2）修改系統參數 arclist標簽另類優化

在DedeCMS V5版本中，官方其實已經做了極力優化，引入了緩存機制。其實影響HTML生成速度的罪魁禍首還是模板中的arclist標簽，很多站長喜歡用arclist標簽來調用最新、熱門、推薦、頭條等文章列表，但是arclist標簽每次都帶著一大堆條件去主表中查詢，可能還會關聯附加表，對一次性生成大量文章來說，只是重復使用arclist標簽對數據庫重復查詢罷了，自然會花去大量時間?，F在DedeCMS新的版本中，生成HTML時arclist標簽會直接調用緩存數據，省去arclist標簽重復查詢數據庫的時間，頓時讓上述工作變得輕松起來，生成速度得到提升也是必然的。你只用在系統參數->性能選項中，找到arclist標簽調用緩存（cfg_index_cache）(0 不啟用，大于0值為多少秒)，根據自身實際需求調整緩存調用時間。

其實，還有一種解決辦法，就是麻煩了一些，但是對性能提升是非常顯著的。arclist標簽調用緩存雖說一定程度上提高了HTML生成速度，但是還是需要對arclist緩存進行判斷，如果能把這部分時間也省去，那是不是會更快呢？答案是肯定確定以及雙重否定。我們可以通過freelist(自由列表)功能事先生成最新、熱門、推薦、頭條等文章列表頁面，然后用include標簽直接引入到模板里，標簽格式為：{dede:include file=’文章列表頁面文件名稱’ ismake=’ no’/}。如果你的站長數據很龐大，服務器硬件配置也一般的話，何不嘗試一下呢？

另外，系統參數-核心設置里默認的關鍵字替換功能（cfg_keyword_replace）是開啟的，如果文章是采集過來的，還是關閉的好，有很多關鍵字都毫無意義，甚至會有亂碼導致生成出錯，關掉此功能對提高系統性能是有一定幫助的。

3）數據庫表索引優化 性能大幅提升

為什么要對DedeCMS數據庫表索引進行優化呢？很簡單，在Mysql中，索引無疑是最有效的加快查詢的工具了，一個合理的索引組合會極大地提升你的查詢效率和系統性能。言歸正傳，你可以通過phpmyadmin或是一個叫Navicat for MySQL的軟件（推薦）來管理你的數據庫。

分析DEDECMS數據表信息，不難發現，所有的文章數據是存儲在dede_archives和dede_arctiny，以及對應的dede_addonarticle附加表中的。生成HTML時，sql查詢主要圍繞這三張表來的。個人認為，凡是要排序的字段和查詢條件的字段及文檔ID都要建立索引，如果一個沒有建立，將會嚴重影響MySQL的查詢效率，最終導致生成速度變慢。DEDECMS數據表索引建立方法如下：

a）dede_archives，是文章的主表，存儲文章標題、關鍵字、描述、發布時間等信息，10萬數據的表大小可能在30MB左右，也是我們優化的重點。你需要建立的索引字段有，id、channel、pubdate、sortrank、ismake、typeid、mainindex、lastpost；其中，像系統默認的mainindex和lastpost這兩個組合索引，個人認為存在意義不大，可以刪除，自己掂量。需要注意的是，click字段，是文檔的點擊數，此字段更新頻率，建立索引后會對系統維護帶來一定壓力，另外也有人說頻繁更新的建立索引會容易導致數據庫損壞，也無從查證。個人建議click字段保留，不建立索引。

b）dede_arctiny，這個表比較小，10萬數據的表大小不到5MB，建議不建立索引，可以將自帶的刪除掉，或者只保留sortrank索引。

c）dede_addonarticle，是文章附加表，主要是用來存儲文章內容的，不作索引考慮。