dedecms负载性能优化实例，三招让你的dedecms快10倍以上第12页-木庄网络博客

本文整理自网络，侵删。

还是因为一个表的大数据造成性能严重下降？难道我们必须通过分多个表来存储才能解决问题吗？以下我们通过一个实例来解析和优化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对数据库的查询操作只是简单机械重复罢了，为此而耗费了大量时间绝对是不值得的。接下来我们给出问题解决的建议。