对于DedeCMS表现出来相对较差的性能感觉比较迷惑，到底是什么在限制其负载效率？难道真的是某些Dede论坛版主说的是因为MySQL不堪重负的原因吗？
我们通过一个实例来解析和优化DedeCMS的数据管理性能，千万别让MySQL当替罪羊。测试数据是重复添加的文章数据，数据量将近110万条。未优化前我们测试发现主要有两个经常性的操作在Dede大数据量的情况下影响管理性能，分别是“文档生成”“列表生成”，接下来我们就针对这两个方面进行优化实践。
改进列表生成速度
1、【问题描述】
接下来我们继续测试列表页面的生成，这次我们学乖了，先把模板list_article.htm中的arclist标签删除后再测试，但是生成效果依然非常不理想，每个列表页面生成时间接近20秒，按照每页50条数据计算，生成单个栏目的3万数据理论上也要花费3个多小时，生成90万数据..这......。由于列表内容使用的是list标签，这是一个和arclist有点类似的标签，因此我们不能延续上一篇文章（改进文章生成速度）的做法来解决问题，只能另辟蹊径。
2、【问题分析】
由于目标锁定在list标签，测试的过程就简单了。我们直接使用织梦中list的查询语句做优化分析，很快发现了问题。我们测试了list中的sql查询语句，以下代码就是list用来查询数据库中对应条件的SQL语句，执行时间大约为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
我们注意到这个SQL语句中的where子句使用了and和or的多种条件判断，经验告诉我们如果查询子句中使用了in或者or语句，会导致全表扫描，这样的话索引的效率就无法体现。我们简化了where子句的判断条件进行测试，结果发现删除了or子句之后，查询效率大幅提升，上面的查询语句只用时不到1秒就获得了查询结果。这就是问题关键。
3、【解决方案】
对于list查询来说，arc.typeid2='1′这个条件目的是查找某个文章所属的第二分类（相当于副栏目），而事实上这个功能在大部分情况下很少使用，因为我们大可使用tag标签来完成一篇文章的多个不同分类的归属，因此我们修改文件inc_arclist_view.php，在查询语句中直接删除了typeid2的条件判断，并在pub_db_mysql.php中改进了查询执行函数（用于提高sql语句执行的效率，对最终结果影响不大，可以省略），得到最终的测试结果，平均每个列表页面的生成时间下降至不到1秒，3万数据600个列表页面生成只需要花费不到10分钟，优化目标达成。
【相关推荐】