对dedecms表现出来的相对较差的性能也感觉比较迷惑，到底是什么在制约其负载效率？难道真的是某些脑残的dede论坛版主说的是因为mysql不堪重负的原因吗？

　　还是因为一个表的大数据造成性能严重下降？难道我们必须通过分多个表来存储才能解决问题吗？以下我们通过一个实例来解析和优化dedecms的数据管理性能，千万别让mysql当替罪羊，罪莫大焉。

　　测试数据是无意中得到的企业黄页的数据，数据量将近90万，都是完全真实的数据，测试使用的程序是dedecms4.0版本，你问为什么不用dedecms5.1？那是因为我们为了优化，针对dedecms做了很多修改，如果使用dedecms5.1，我们害怕收到法院传票……，补充一句，以下的优化方法均能在dedecms5.1中使用，请在理解其原理的基础上自行完成。

　　未优化前我们测试发现主要有三个经常性的操作在dede大数据量的情况下影响管理性能，分别是文档生成、列表页生成和栏目列出所有文章，我们就针对这三个方面进行优化实践。

　　以下是测试数据的基本信息：

　　文档数量接近90万

　　每个栏目包含近3万数据

　　1.改进文档生成速度

　　问题提出

　　和我们前一次测评结果相同，dedecms的文档的生成速度惨不忍睹。使用默认模板（article_article.htm），平均接近30秒才能生成20个页面（如图），按照这个速度生成下去，90万的数据全部生成网页能等到头发都白了。那么到底问题在哪里呢？

　　优化前单个栏目文档生成速度

　　问题分析

　　先排除表索引的问题，因为dede的数据库已经在数据主表（dede_archives）为主要字段都建立了索引。再排除主要内容的提取效率问题，因为页面生成过程中读取页面中的文章数据，每次需要到主表和附表中select取得id值唯一的数据内容，这个SQL语句的效率我们通过直接在mysql中运行SQL语句测试，执行时间非常短，因此这也不是最大的瓶颈。

　　终于在页面生成过程中，我们发现程序执行了数次主表（dede_archives）查询，并取出符合一组复杂查询条件数据的操作，查询效率非常低，原来是它在影响效率！通过调试跟踪，我们定位了问题的关键，元凶就是模板中arclist标签。Arclist标签是很多人很喜欢用的标签，因为它比较灵活，能从数据中取出热门、最新、相关等各种类型的文章列表，但是arclist标签每次都会带着一大推搜索条件去主表中查询，实际上对于一次性生成大量文章来说，如果使用相同的模板，arclist对数据库的查询操作只是简单机械重复罢了，为此而耗费了大量时间绝对是不值得的。接下来我们给出问题解决的建议。

　　解决问题

　　解决方案1：去掉最终页面模板中的arclist标签，或者尽可能少用。这个方法虽然能极大提高效率，但是无异于泼水把孩子泼走了，对于企图增加访问pv的网站来说，不建议使用。

　　解决方案2：建立arclist缓存，将每次arclist生成的数据放到临时目录或者缓存当中，在文档生成过程中判断缓存是否有更新，如果无更新，直接使用缓存数据。这个方法无需改变模板，对于提高生成效率也有一定的效果，但由于对程序改动较大，酌情考虑使用。

　　解决方案3：也是小组建议的解决方案，那就是充分挖掘现有dedecms的功能，在尽量不改变程序的基础上，大幅提高效率。具体的方法就是通过freelist（自由列表生成）功能事先生成热门文章、最新文章、相关文章等内容的列表页面，然后使用dedecms提供的include标签直接引入文档页面。标签格式为：{dede:include file='列表页面文件名称' ismake=' no'/}。这个方案优点在于仅增加部分操作步骤，没有改动任何程序，性能提高亦非常明显。下图就是我们利用这个方法优化后的生成速度，仅用时50秒就完成了1500多页的文章生成，达成目标优化效果。此方案由于增加了操作步骤，懒人慎用。

　　优化后单个栏目文档生成速度

　　2.改进列表页面生成速度

　　问题提出

　　接下来我们继续测试列表页面的生成，这次我们学乖了，先把模板（list_article.htm）中的arclist标签删除后再测试，但是生成效果依然非常不理想。如下图，每个列表页面生成时间接近20秒（我们修改了页面结果输出提示，为了大家更方便看到每个列表页面生成时间），按照每页50条数据计算，生成单个栏目的3万数据理论上也要花费3个多小时，生成90万数据……无语ing。由于列表内容使用的是list标签，这是一个和arclist有点类似的标签，因此我们不能延续上面的做法来解决问题，只能另辟蹊径。

　　优化前的列表页面生成速度

　　问题分析

　　由于目标锁定在list标签，测试的过程就简单了。我们直接使用dedecms中list的查询语句做优化分析，很快发现了问题。我们测试了list中的sql查询语句，以下代码就是list用来查询数据库中对应条件的SQL语句，执行时间大约为15秒，效率很不理想。

　　Select arc.ID,arc.title,arc.iscommend,arc.color, arc.typeid,arc.ismake,arc.money,arc.description,ar c.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

　　我们注意到这个SQL语句中的where子句使用了and和or的多种条件判断，经验告诉我们如果查询子句中使用了in或者or语句，会导致全表扫描，这样的话索引的效率就无法体现。我们简化了where子句的判断条件进行测试，结果发现删除了or子句之后，查询效率大幅提升，上面的查询语句只用时不到1秒就获得了查询结果。这就是问题关键。

　　解决问题

　　对于list查询来说，arc.typeid2='1′这个条件目的是查找某个文章所属的第二分类，而事实上这个功能在大部分情况下很少使用，因为我们大可使用标签（tag）来完成一篇文章的多个不同分类的归属，因此我们修改文件inc_arclist_view.php，在查询语句中直接删除了typeid2的条件判断，并在pub_db_mysql.php中改进了查询执行函数（主要用于提高sql语句执行的效率，对最终结果影响不大），得到的最终测试结果如下，平均每个列表页面的生成时间下讲到不到1秒，3万数据600个列表页面生成只需要花费不到10分钟，优化目标达成。