误区一：SQL 慢，加索引

多数情况下，数据库可能是瓶颈。通过 Slow Query Log 发现执行时间比较长的 SQL 并不难，于是有的人一看 SQL 走了全表扫描，干脆添加个索引好了。

其实这个地方值得商榷的。第一，必须确定一下该 SQL 执行次数到底是怎样的? 执行真的很频繁? 那么对应的页面是否通过 Cache 可以减少对 DB 的冲击? 如果可以，尽量不要添加索引，索引本身对表的负面影响也是很大的，比如降低更新速度，影响并发能力等。

误区二：瓶颈一定在数据库上

前面说，数据库”可能”是瓶颈，但不总是瓶颈，优化的第一步，必需要有针对瓶颈优化。很多时候，图片访问带来的压力甚至比数据库压力还大 — 有的用户数据库、用户上传的图片文件、Web 服务器都扔到一台服务器上，这时候，第一手去调整 MySQL 或许会有作用，但价值不大。

应该说，瓶颈的有效定位的确是个技术活儿，对于一个新的论坛环境，也有人用逐一尝试法来做，这倒也没什么。

误区四：盲目的静态编译 MySQL

静态编译 MySQL 有好处，但如果系统已经在线上运行了，在原有环境中进行静态编译未必能带来多大好处。我问过一些朋友，静态编译到底带来多大好处? 没有几个人能说清楚。

对于 PHP 也是这样，如果一次优化从其它方式上能带来更清晰、直接的开销，就不要重新编译

误区五：反复尝试，但不建立基准数据

这其实是第四点的延伸。而建立基准数据，实在应该是优化的最基本的步骤。这样才能有效的评估优化的效果。否则的话，象误区一描述的，添加了一个索引，短期内可能感觉快了，长期看，性能可能又会慢下来。

误区六：一次进行多个优化步骤

这可能是比较普遍的”习惯”了，有的朋友喜欢一次调整多个参数或是多个环境的设置，然后观察效果。如果每个步骤都是”对”的话，那么效果看起来是好的。如果有的步骤调节”错”的话，可能会抵消那些有效果的优化步骤。

优化策略是个见仁见智的问题。以上只是个人浅见，欢迎留言探讨。

一、关于模板引擎的前言
从phplib到smarty，再到Discuz!的模板机制，本文试图通过PHP模板引擎为你讲解作者自己的PHP心得。

我清楚的记得在我刚上大学开始学习PHP的时候，曾经在phpe.net看到过一篇关于phplib Template和FastTemplate这两模板引擎性能比较的文章。让我在接下来半年的时间内持续的使用着phplib。不可否认phplib是左右了一代PHP开发人员对于PHP模板引擎的认识。或许你也会对下面的方法比较熟悉

$t->set_file
$t->set_var
当我对于phplib的执行效率不满意的时候，我开始寻找下一个PHP的模板引擎，于是smarty跳入我的视野范围，当我费尽心血去学会了smarty并使用开发了很多东西，而现在的我突然发现记得的也就只有下面的方法了

$s->assign
$s->display

究竟我们需要模板引擎来做什么呢，MVC？简单？易用？效率？请看下文的分析。

二、程序处理的分析

1.PHPLIB的程序处理过程
从phplib的处理开始讲起

$t = new Template()
$t->set_file
$t->set_var
$t->parse
$t->p

看上面的代码，翻译成中文就是

[*]初始化模板类$t
[*]设置模板文件
[*]设置模板变量
[*]分析模板文件中的模板变量
[*]输出内容

通过了最少5个步骤在php程序中实现模板的处理

2.Smarty的程序处理过程
现在来看smarty的处理
$s = new Smarty
$s->assign
$s->display

翻译成中文就是

[*]初始化模板类$s
[*]设置模板变量
[*]解析并输出模板

3.Discuz!模板的程序处理过程
include template(tplname);

主要作用就是指定给程序需要处理的模板文件

在上述三种模板处理机制中，最容易理解和接受就是Discuz!模板的处理过程。初始化、设置变量、解析模板、输出内容，Discuz!只用了一个函数来做。对于一个开源的论坛软件，这样处理的好处是显而易见的，对于Discuz!进行二次开发的程序员的要求降低。简化模板语言，方便风格和插件的制作，这也在一定程度上促进了Discuz!的传播

三、模板源文件的语法

在phplib中处理循环嵌套的时候，使用：
<!–    BEGIN row   –>
{it}
<!–     END row    –>
在smarty中处理循环嵌套的时候，引入了
<{section name=loopName loop=$loopArray}>（当然还有foreach这样的）
在Discuz!中处理循环嵌套的时候，
<!–{loop $array $value}–>
其实真正的模板面对的可以说是不懂PHP或者懂一点PHP的美工同志们，模板的复杂就意味着美工制作页面的难度加大。在必不可少的需要模板有逻辑处理的时候，为什么不在html代码中使用原生态的PHP语法，而让美工相当于去学习另外一种语言呢？在我个人的经验中，显然是Discuz!的模板语言更为简单易学，也为我节省了更多的时间。

四、Discuz!模板处理机制
我剥离出一个简单的Discuz!模板处理函数

function template($file, $templateid = 0, $tpldir = ”) {

$tplfile = DISCUZ_ROOT.’./’.$tpldir.’/’.$file.’.htm’;//模板源文件，此处$tplfile变量的值可能是D:\discuz\templates\default\demo.htm
$objfile = DISCUZ_ROOT.’./forumdata/templates/’.$templateid.’_’.$file.’.tpl.php’;//模板缓存文件，此处$objfile变量的值可能是D:\discuz\forumdata\templates\1_demo.tpl.php

//如果模板源文件的修改时间迟于模板缓存文件的修改时间，
//就是模板源文件被修改而模板缓存没有更新的时候，
//则调用parse_template函数重新生成模板缓存文件。
if(@filemtime($tplfile) > @filemtime($objfile)) {
require_once DISCUZ_ROOT.’./include/template.func.php’;
parse_template($file, $templateid, $tpldir);
}

//返回缓存文件名称
//$objfile变量内容可能为D:\discuz\forumdata\templates\1_demo.tpl.php
return $objfile;
}
而php页面的模板执行语句

include template(’demo’);

实际上在本例中就是相当于

include ‘D:\discuz\forumdata\templates\1_demo.tpl.php’;

这个流程就是一个demo.php文件中当数据处理完成以后include template(’demo’)，去显示页面。

五、总结
我也曾经看到过有列举出很多种的PHP模板引擎，但是我觉着phplib、smarty、Discuz!模板机制就足以说明问题了。

1.我们需要模板来做什么？
分离程序与界面，为程序开发以及后期维护提供方便。

2.我们还在关心什么？
PHP模板引擎的效率，易用性，可维护性。

3.最后的要求什么？
简单就是美！

我的文章好像没有写完，其实已经写完了，我要说明的就是从PHP的模板引擎看Discuz!模板机制。分析已经完成，或许以后我会再写篇实际数据的测试供给大家参考！