還是因?yàn)橐粋€(gè)表的大數(shù)據(jù)造成性能?chē)?yán)重下降？難道我們必須通過(guò)分多個(gè)表來(lái)存儲(chǔ)才能解決問(wèn)題嗎？以下我們通過(guò)一個(gè)實(shí)例來(lái)解析和優(yōu)化dedecms的數(shù)據(jù)管理性能，千萬(wàn)別讓mysql當(dāng)替罪羊，罪莫大焉。
測(cè)試數(shù)據(jù)是無(wú)意中得到的企業(yè)黃頁(yè)的數(shù)據(jù)，數(shù)據(jù)量將近90萬(wàn)，都是完全真實(shí)的數(shù)據(jù)，測(cè)試使用的程序是dedecms4.0版本，你問(wèn)為什么不用dedecms5.1？那是因?yàn)槲覀優(yōu)榱藘?yōu)化，針對(duì)dedecms做了很多修改，如果使用dedecms5.1，我們害怕收到法院傳票……，補(bǔ)充一句，以下的優(yōu)化方法均能在dedecms5.1中使用，請(qǐng)?jiān)诶斫馄湓淼幕A(chǔ)上自行完成。

未優(yōu)化前我們測(cè)試發(fā)現(xiàn)主要有三個(gè)經(jīng)常性的操作在dede大數(shù)據(jù)量的情況下影響管理性能，分別是文檔生成、列表頁(yè)生成和欄目列出所有文章，我們就針對(duì)這三個(gè)方面進(jìn)行優(yōu)化實(shí)踐。
以下是測(cè)試數(shù)據(jù)的基本信息：

文檔數(shù)量接近90萬(wàn)

每個(gè)欄目包含近3萬(wàn)數(shù)據(jù)

1.改進(jìn)文檔生成速度

問(wèn)題提出

        和我們前一次測(cè)評(píng)結(jié)果相同，dedecms的文檔的生成速度慘不忍睹。使用默認(rèn)模板（article_article.htm），平均接近30秒才能生成20個(gè)頁(yè)面（如圖），按照這個(gè)速度生成下去，90萬(wàn)的數(shù)據(jù)全部生成網(wǎng)頁(yè)能等到頭發(fā)都白了。那么到底問(wèn)題在哪里呢？

優(yōu)化前單個(gè)欄目文檔生成速度

問(wèn)題分析

        先排除表索引的問(wèn)題，因?yàn)閐ede的數(shù)據(jù)庫(kù)已經(jīng)在數(shù)據(jù)主表（dede_archives）為主要字段都建立了索引。再排除主要內(nèi)容的提取效率問(wèn)題，因?yàn)轫?yè)面生成過(guò)程中讀取頁(yè)面中的文章數(shù)據(jù)，每次需要到主表和附表中select取得id值唯一的數(shù)據(jù)內(nèi)容，這個(gè)SQL語(yǔ)句的效率我們通過(guò)直接在mysql中運(yùn)行SQL語(yǔ)句測(cè)試，執(zhí)行時(shí)間非常短，因此這也不是最大的瓶頸。

        終于在頁(yè)面生成過(guò)程中，我們發(fā)現(xiàn)程序執(zhí)行了數(shù)次主表（dede_archives）查詢，并取出符合一組復(fù)雜查詢條件數(shù)據(jù)的操作，查詢效率非常低，原來(lái)是它在影響效率！通過(guò)調(diào)試跟蹤，我們定位了問(wèn)題的關(guān)鍵，元兇就是模板中arclist標(biāo)簽。Arclist標(biāo)簽是很多人很喜歡用的標(biāo)簽，因?yàn)樗容^靈活，能從數(shù)據(jù)中取出熱門(mén)、最新、相關(guān)等各種類(lèi)型的文章列表，但是arclist標(biāo)簽每次都會(huì)帶著一大推搜索條件去主表中查詢，實(shí)際上對(duì)于一次性生成大量文章來(lái)說(shuō)，如果使用相同的模板，arclist對(duì)數(shù)據(jù)庫(kù)的查詢操作只是簡(jiǎn)單機(jī)械重復(fù)罷了，為此而耗費(fèi)了大量時(shí)間絕對(duì)是不值得的。接下來(lái)我們給出問(wèn)題解決的建議。

解決問(wèn)題

解決方案1：去掉最終頁(yè)面模板中的arclist標(biāo)簽，或者盡可能少用。這個(gè)方法雖然能極大提高效率，但是無(wú)異于潑水把孩子潑走了，對(duì)于企圖增加訪問(wèn)pv的網(wǎng)站來(lái)說(shuō)，不建議使用。

解決方案2：建立arclist緩存，將每次arclist生成的數(shù)據(jù)放到臨時(shí)目錄或者緩存當(dāng)中，在文檔生成過(guò)程中判斷緩存是否有更新，如果無(wú)更新，直接使用緩存數(shù)據(jù)。這個(gè)方法無(wú)需改變模板，對(duì)于提高生成效率也有一定的效果，但由于對(duì)程序改動(dòng)較大，酌情考慮使用。

解決方案3：也是小組建議的解決方案，那就是充分挖掘現(xiàn)有dedecms的功能，在盡量不改變程序的基礎(chǔ)上，大幅提高效率。具體的方法就是通過(guò)freelist（自由列表生成）功能事先生成熱門(mén)文章、最新文章、相關(guān)文章等內(nèi)容的列表頁(yè)面，然后使用dedecms提供的include標(biāo)簽直接引入文檔頁(yè)面。標(biāo)簽格式為：{dede:include file='列表頁(yè)面文件名稱(chēng)' ismake=' no'/}。這個(gè)方案優(yōu)點(diǎn)在于僅增加部分操作步驟，沒(méi)有改動(dòng)任何程序，性能提高亦非常明顯。下圖就是我們利用這個(gè)方法優(yōu)化后的生成速度，僅用時(shí)50秒就完成了1500多頁(yè)的文章生成，達(dá)成目標(biāo)優(yōu)化效果。此方案由于增加了操作步驟，懶人慎用。

優(yōu)化后單個(gè)欄目文檔生成速度

2.改進(jìn)列表頁(yè)面生成速度

問(wèn)題提出

        接下來(lái)我們繼續(xù)測(cè)試列表頁(yè)面的生成，這次我們學(xué)乖了，先把模板（list_article.htm）中的arclist標(biāo)簽刪除后再測(cè)試，但是生成效果依然非常不理想。如下圖，每個(gè)列表頁(yè)面生成時(shí)間接近20秒（我們修改了頁(yè)面結(jié)果輸出提示，為了大家更方便看到每個(gè)列表頁(yè)面生成時(shí)間），按照每頁(yè)50條數(shù)據(jù)計(jì)算，生成單個(gè)欄目的3萬(wàn)數(shù)據(jù)理論上也要花費(fèi)3個(gè)多小時(shí)，生成90萬(wàn)數(shù)據(jù)……無(wú)語(yǔ)ing。由于列表內(nèi)容使用的是list標(biāo)簽，這是一個(gè)和arclist有點(diǎn)類(lèi)似的標(biāo)簽，因此我們不能延續(xù)上面的做法來(lái)解決問(wèn)題，只能另辟蹊徑。

優(yōu)化前的列表頁(yè)面生成速度

問(wèn)題分析

        由于目標(biāo)鎖定在list標(biāo)簽，測(cè)試的過(guò)程就簡(jiǎn)單了。我們直接使用dedecms中l(wèi)ist的查詢語(yǔ)句做優(yōu)化分析，很快發(fā)現(xiàn)了問(wèn)題。我們測(cè)試了list中的sql查詢語(yǔ)句，以下代碼就是list用來(lái)查詢數(shù)據(jù)庫(kù)中對(duì)應(yīng)條件的SQL語(yǔ)句，執(zhí)行時(shí)間大約為15秒，效率很不理想。

Select arc.ID,arc.title,arc.iscommend,arc.color, arc.typeid,arc.ismake,arc.money,arc.description,arc.shorttitle, arc.memberid,arc.writer,arc.postnum,arc.lastpost, arc.pubdate,arc.senddate,arc.arcrank,arc.click,arc.litpic, tp.typedir,tp.typename,tp.isdefault,tp.defaultname, tp.namerule,tp.namerule2,tp.ispart,tp.moresite,tp.siteurl from dede_archives arc left join dede_arctype tp on arc.typeid=tp.ID left join qiye_addonarticle on arc.ID = qiye_addonarticle.aid where arc.arcrank > -1 And ( ( arc.typeid='1′ ) or arc.typeid2='1′) order by arc.sortrank desc limit 0,50

        我們注意到這個(gè)SQL語(yǔ)句中的where子句使用了and和or的多種條件判斷，經(jīng)驗(yàn)告訴我們?nèi)绻樵冏泳渲惺褂昧薸n或者or語(yǔ)句，會(huì)導(dǎo)致全表掃描，這樣的話索引的效率就無(wú)法體現(xiàn)。我們簡(jiǎn)化了where子句的判斷條件進(jìn)行測(cè)試，結(jié)果發(fā)現(xiàn)刪除了or子句之后，查詢效率大幅提升，上面的查詢語(yǔ)句只用時(shí)不到1秒就獲得了查詢結(jié)果。這就是問(wèn)題關(guān)鍵。