很多 Discuz! 的用户在论坛规模达到一定程度上，就要经常性的考虑优化的问题。现在网络上的很多热心的技术人都分享了 Discuz! 的优化经验，应该说，很多经验还是不错的，但也有的帖子可能会让用户走入误区。
误区一：SQL 慢，加索引
多数情况下，数据库可能是瓶颈。通过 Slow Query Log 发现执行时间比较长的 SQL 并不难，于是有的人一看 SQL 走了全表扫描，干脆添加个索引好了。
其实这个地方值得商榷的。第一，必须确定一下该 SQL 执行次数到底是怎样的? 执行真的很频繁? 那么对应的页面是否通过 Cache 可以减少对 DB 的冲击? 如果可以，尽量不要添加索引，索引本身对表的负面影响也是很大的，比如降低更新速度，影响并发能力等。
误区二：瓶颈一定在数据库上
前面说，数据库”可能”是瓶颈，但不总是瓶颈，优化的第一步，必需要有针对瓶颈优化。很多时候，图片访问带来的压力甚至比数据库压力还大 — 有的用户数据库、用户上传的图片文件、Web 服务器都扔到一台服务器上，这时候，第一手去调整 MySQL 或许会有作用，但价值不大。
应该说，瓶颈的有效定位的确是个技术活儿，对于一个新的论坛环境，也有人用逐一尝试法来做，这倒也没什么。
误区四：盲目的静态编译 MySQL
静态编译 MySQL 有好处，但如果系统已经在线上运行了，在原有环境中进行静态编译未必能带来多大好处。我问过一些朋友，静态编译到底带来多大好处? 没有几个人能说清楚。
对于 PHP 也是这样，如果一次优化从其它方式上能带来更清晰、直接的开销，就不要重新编译
误区五：反复尝试，但不建立基准数据
这其实是第四点的延伸。而建立基准数据，实在应该是优化的最基本的步骤。这样才能有效的评估优化的效果。否则的话，象误区一描述的，添加了一个索引，短期内可能感觉快了，长期看，性能可能又会慢下来。
误区六：一次进行多个优化步骤
这可能是比较普遍的”习惯”了，有的朋友喜欢一次调整多个参数或是多个环境的设置，然后观察效果。如果每个步骤都是”对”的话，那么效果看起来是好的。如果有的步骤调节”错”的话，可能会抵消那些有效果的优化步骤。
优化策略是个见仁见智的问题。以上只是个人浅见，欢迎留言探讨。
–EOF–
优化永远是一个有趣的话题。
很多时候论坛的速度都是被某些垃圾插件拖累的。
我们公司最近也在考虑一个优化，目前我们是基于squid的静态cache，所以假如做单篇文章的查询cache （memcache），意义大吗，是增加了应用的复杂度，还是这层cache是否有效
@dongdong
先找出来问题所在，然后再找解决办法
查询 Cache 用好了当然不错。但这是否能解决问题还是未知数
要是有纯静态优化就好了
感觉在建立的时候考虑周全才是最重要的
事后拆东墙补西墙的…
“大猫 的评论:
感觉在建立的时候考虑周全才是最重要的
事后拆东墙补西墙的…”
一个项目如果想一开始或者第一阶段就做完美，这个项目失败和流产几乎是定数。
这篇不错。
其实优化是一个方法论的活。首先要有正确的方法和流程，然后才是办法。
没有基准测试的优化等于白做。很多事情是让A增加10%，让B减少50%。
我之前那个blog也写过，可惜这种越浅显的道理，大家越觉得无所谓，但是又在不停的重复犯错误。
对于第一条，加索引甚至可能不能解决全表扫描的问题。
Discuz!负载优化还是有很多东西可写的，有空我来写篇。嘎嘎！
顺带说下Fenng这里的验证码不能刷新。
@kimi
我这个验证码，就别提了，的确有些糟糕
另，期待你的 Discuz! 文章
“反复尝试，但不建立基准数据”
这个讲到的基准数据,想问下什么是基准数据.
谢谢!
mysql在多数小型应用下需要微调参数来进行优化
特别是很多单台服务器的小应用