Think Again » 数据库

WordPress数据库查询三板斧之三:如何查看WP数据库查询的具体内容

山之岚 — Tue, 29 Jul 2008 12:42:27 +0000

本文将继续来探讨Wordpress数据库查询的相关话题。文一里，我们知道了WP各个基准页面所需的数据库查询量。文二中，我介绍了利用WP自带技术实现降低数据库查询或读取次数的方法，将此法应用于模板中，可在不影响互动前提下，降低模板的数据库查询次数。如果您想了解下到底是那些函数或插件在消耗这些数据库查询呢？以及每个查询WP都从数据库中读什么东东呢？本文将帮您揭开这些问题的谜底。

照旧，一切都是利用WP自带技术的。继续拿起铲子，深挖WORDPRESS。

首先，先用文本编辑器打开wp-config.php，加入如下代码：

define(‘SAVEQUERIES’, true);

此行代码，将激活定义WP把每次数据查询的信息保存到数组内。然后用下述代码将数组内的各次数据库查询的信息显示出来，具体内容有三项：各次数据库查询的SQL代码，读取所消耗时间和执行数据库查询的函数名称。

if (is_user_logged_in()){   2:     global $wpdb;   3:     echo "";
    print_r($wpdb->queries);
    echo "";   6: }

来看看上面这6行代码，第1和6行代码用于判断当前用户是否是注册用户，如果您愿意让普通浏览者看见这些分析结果，可以将这2行代码去掉。第2行，定义全局变量$wpdb，这是WP默认的数据库类。第3和5行，定义将分析结果嵌套在HTML

WordPress数据库查询三板斧之二:如何减少WP数据库查询次数和提高运行效率

山之岚 — Fri, 25 Jul 2008 05:06:04 +0000

Updated: 2008-07-26，更新Hook代码。

续上文，通过WordPress基准页面数据库查询次数统计，让我们对WP运行各页面所需最少查询数有个基本了解。分析这些基准页面所需的数据库查询次数的目的当然是想减低它们，以提高WP运行效率了。本文将就如何不借助外部方法，仅利用Wordpress自带技术来减少Wordpress数据库查询次数和提高运行效率，谈谈我的个人做法和思路。欢迎拍砖。本文假设阅读者应了解WP的基本知识，并能操作简单的PHP代码。

要想减少数据库的查询次数，首先要对模板进行分析，了解到模板中的哪个部分功能需要调用数据库，以及哪些些插件需要读写数据库。然后在此基础上，再来分析下减少的可能性。此文主要以模板为例，插件部分暂且不谈。以ThinkAgain现用模板为例，来分析下页面中的哪几个部分需要读取数据库。如在首页的最新留言，最新存档，目录树和标签云等这些都需要从数据库中读取相应的数据，至于日历，WP已经内置了缓存。进一步考虑下，这些东西在未有新事件前，(如新留言或新文章发布等)，每次加载页面读取数据库并生成的html代码的内容都是一样的，既然如此有必要在每次加载页面时，重复这些事情，如果能将这部分内容缓存起来岂不就可以减少数据库读取次数以及提高WP运行效率了吗？OK，这个就是我对精简数据库查询次数的主要思路之一。当然，接下来要解决如何实现缓存问题以及自动更新的问题。

先来看一组数据，让数字来说话。

上图是DH提供的数据库使用情况统计数字，可以看出，从19日到21日，每次数据库链接所消耗的查询次数均值大概在29.1~30.6，22日下午开始换上更改后的代码，启用缓存，22日平均查询次数降低到25.2，23日的平均值就更低了约为20次。大约降低了33%左右。效果还是很显著的吧。

接下来，来谈谈具体如何缓存以及如何解决即时更新的问题。

1. 缓存问题

缓存数据的方法虽然很多，其实按性质划分起来无非就只有2种，缓存到数据库或者缓存文件。后者，记得水煮鱼写过一篇怎样缓存sidebar的文章，简单地说，其思路为利用output control function将侧边栏内容缓存到sidebar.html文件中，然后定时进行更新。此法可以解决缓存问题以及减少数据库查询，唯一不足的就是在指定间隔时间内容，新留言的无法自动更新。p.s，这问题实际上利用WP运行机制是可以解决的。

而我的方法是将数据缓存到数据库中，然后在使用时仍然从数据库中读取。如此做法不是还要读取数据库么？怎么会减少数据库查询次数呢？先别急，且听我慢慢道来。

默认WP有10个数据表，wp_posts和comments主要存储文章内容和评论，其它的几个包括term等存储了目录和标签等等。这里不细谈。wp_options用来存储Wordpress以及插件运行时所涉及的配置等。且WP会在运行时自动读取该表的内容。换句话说，因为WP已经预读这部分内容，所以直接调用wp_options内的数据是不会产生数据库查询的。到此为止，谜底已经揭开了一大半了。高手们不用往下看，也都知道怎么做了吧。呵呵。

2. 即时更新问题

有了新留言或发布了新文章，自然想马上在页面中显示出来，这就需要即时更新已缓存在wp_options里面的数据。要解决这个问题，自然还是要从Wordpress的运行机制方面下手。

此文中，我曾简单地谈过WP是个好东西，提供了一个框架平台，也开放了很多预定义的接口给用户自定义。从系统分析的角度来看，WP也是个离散系统。从用户点击网址，WP解析url开始等，发表评论或文章等等，这些都可以视为一个离散事件。而WP提供了很完备的Hook用于用户对这些事件进行控制。

缓存的内容涉及最新留言，或文章数的显示等，这些无非都需要在新留言或新文章发布这些事件发生后激活更新缓存。理解了这点，也就很容解决问题了。发布新留言和新文章的Hook接口为：

add_action(‘comment_post’, ‘Your_Function’); //comment发布Hook

add_action(‘publish_post’, ‘Your_Function’); //post发布Hook

2个问题都清楚，画个流程图也很简单了。

行文至此，我已经将这个问题的Know-How解释清楚了。老鸟么，可以到此止步。小鸟们继续往下看我给的一个例子。

下面我将给出一个自己写的将最新留言缓存到wp_options表中，以及读取最新留言的2个函数(共3个函数)。有兴趣可以Copy下来放在自己模板的Function.php中，就可以激活使用了。然后在侧边栏的显示最新留言位置，将原来代码替换成

就可以了。

简单介绍下，cache_recent_comments()函数用来显示缓存后的最新留言，cache_get_recent_comments()用来获取最新留言并缓存到wp_options表中。my_utf8_trim()，这个函数是中文工具箱的，其作用在于避免留言被截断后尾部出现乱码。在这里放上来，免得有些网友没有装中文工具箱造成不便。

   1: //显示缓存后的最新留言   2: function cache_recent_comments(){   3:     $cached = get_option('multicolor_cache_recent_comments');//从options表中获取已缓存的最新留言   4:     if($cached){    //如果最新留言已缓存，直接显示，否则获取最新留言并缓存到options表中。   5:         echo $cached;    6:     }else{   7:         $cached = cache_get_recent_comments();   8:         echo "Cache Updated";   9:         echo $cached;  10:     }  11: }  12: //获取最新留言并缓存到options表中  13: function cache_get_recent_comments() {  14:     $commentnumber = 6;    //显示最新留言数目  15:     $before = ' ';    //留言前后html标签
  16:     $after = '';      17:     $length = 150;        //截取留言的长度  18:     global $wpdb;  19:     $sql = "SELECT ID, comment_ID, comment_author_url, comment_content, comment_author FROM $wpdb->posts, $wpdb->comments WHERE $wpdb->posts.ID=$wpdb->comments.comment_post_ID AND ($wpdb->posts.post_status = 'publish')";  20:     $sql .= "AND comment_approved = '1' ORDER BY $wpdb->comments.comment_date DESC LIMIT $commentnumber";  21:     $comments = $wpdb->get_results($sql);  22:     $output = '';  23:     foreach ($comments as $comment) {  24:         $comment_author = stripslashes($comment->comment_author);  25:         $comment_author_url = stripslashes($comment->comment_author_url);  26:         $comment_content = strip_tags($comment->comment_content);  27:         $comment_content = stripslashes($comment_content);  28:         $comment_excerpt =substr($comment_content,0,$length);  29:         $comment_excerpt = convert_smilies($comment_excerpt);  30:         $comment_excerpt = my_utf8_trim($comment_excerpt);  31:         $permalink = get_permalink($comment->ID)."#comment-".$comment->comment_ID;  32:         if (!empty($comment_author_url)){  33:         $comment_author_link = ''" target="_blank" href="'. $comment_author_url . '">'. $comment_author . '';  34:         }else{  35:             $comment_author_link = ''" target="_blank" href="'. $permalink  . '">'. $comment_author . '';  36:         }  37:         $output .= $before . $comment_author_link . ': ' . ''" title="View the entire comment by ' . $comment_author . '">'  . $comment_excerpt . '...' . ''  . $after;  38:         }  39:         update_option('multicolor_cache_recent_comments', $output); //更新缓存在options表中的最新留言  40:         return $output;  41: }  42: //中文工具箱的函数，用于砍掉汉字截断尾巴可能存在的乱码。  43: function my_utf8_trim($str) {  44:     $len = strlen($str);  45:     for ($i=strlen($str)-1; $i>=0; $i-=1){  46:         $hex .= ' '.ord($str[$i]);  47:         $ch = ord($str[$i]);  48:         if (($ch & 128)==0) return(substr($str,0,$i));  49:         if (($ch & 192)==192) return(substr($str,0,$i));  50:     }  51:     return($str.$hex);  52: }  53:     //通过此添加此Hook以保证最新留言能够被缓存到options表中。  54:     add_action('comment_post', 'cache_get_recent_comments');  55:     add_action('edit_comment', 'cache_get_recent_comments');

上述代码只是个例子，仅仅提供了缓存最新留言的功能。这里将代码放上来，目的在于参考。拿来主义固然可以解决目前问题，自己动手方能巩固所学。Do It Yourself才是真正的乐趣。否则的话，玩转WP也就失去意义了。

或许有些网友可能会说，做这些事情干什么？直接静态化不就可以了。通过直接生成实际的html文件固然有其好处，完全不需要php解析和数据库查询等，然后实际应用中，还需要解决一些问题，如一些互动信息，最新留言文章等，一旦静态化后，这部分内容就被定格了。再则，静态化插件很容易和一些下载插件存在兼容性问题，在点击这些下载插件生成的url时，很容易出现返回404错误。等等。

通过分析模板内容，我写了几个简单的函数将各页面中的通用部分缓存到数据库中，可以在一定程度上减少数据库查询次数。如原来这个模板首页需要36次查询，现在为25次。文章页为41次查询，现在为32次。当然，此法并非能解决所有问题，如文章页中的推荐阅读，因为推荐阅读涉及2个方面，一是和该post相关，也就是说要传递post id，在wp_options中给每个post id分个键值，显然是不可取的，二是推荐阅读的内容能自动和新发布文章挂钩。

实际上，我现在模板的数据库查询还是非常高的，主要是当时制作时根本就没有考虑这方面的影响。如果能在模板制作时，将数据库查询问题考虑进去，这样就能最大程度地减低查询数了。

以上的东西能否制作成插件？答案是可以的。制作一个插件提供缓存的留言，文章，标签等功能的显示，乃至可以提供现有wp内置widget提供功能的缓存。然而这并非是我写此文的目的了。分享和探讨，这才是我的初衷。当然如果需要多了，写个插件也未尝不可。

p.s，关于插件制作，上次和牛人Askie瞎聊过这方面的事情。也没有整理，直接放上来。至于为何称此君为牛人呢，您说连Blog地址都是pkphp，能和php PK的人，能不牛乎？

me: 其实现在插件很多了。

10:34 PM 写一些普通作用的插件也没什么意思的。关键是idea。

我挺欣赏你的那个加水印的插件

imaskie: 哈哈

看见你的夸奖了

10:35 PM me: 要写就弄些有点新意的东西，要么就不要再去折腾普通的插件。

imaskie: 奥

10:36 PM 人家有的就不去重复了

me: 弄普通的插件，这么浪费你这人才么，呵呵

imaskie: 哈哈

me: 人家有的，再去弄，除非方法或效率方面有提高，否则有什么意思。你说呢。

imaskie: 是呀

10:37 PM me: 这就像转载人家文章似的。

imaskie: 恩

看见你的博客里的内容了

都是原创

很有技术

不错

me: 哎，谢谢夸奖啊。都是自己在瞎弄。

10:38 PM 要不瞎弄，怎么玩wp。呵呵

其实坛子上很多朋友的问题，只需要他们自己动手测试下，大部分都可以自己解决的。

OK，到此结束，欢迎拍砖。

评论12:

12.2011.09.13.6:56.pm. ruantoo: 这个学习了~~~~ 我的数据库查询达到112次亲娘要命呀真该急救了

11.2011.04.22.8:41.am. DH: 我知道了，是个空间商的名字

10.2011.04.15.12:46.pm. DH: “DH提供的数据库使用情况统计数字” 这个DH是什么啊？

9.2008.08.01.2:35.pm. ddkk3000: 磁盘缓存载入快还是数据库直接载入快，这个没有弄懂。

8.2008.07.26.9:56.pm. 山之岚: To Oyster: 呵呵，这里我也要纠正你的一些错误观点哦。 1.WP本身并不具有缓存机制。但如果你的php支持一些缓存扩展，如memcached，且在wp-config.php中开启wp_cache。wp的缓存机制才会利用这些缓存扩展运行。 2.之所以会被认为wp有缓存机制，是因为wp在打开页面时候，就默认将wp_options里面autoload为true的键值（数据）加载了。这也就是我的方法不需要数据查询的原因之一，因为它们已经默认被加载了。 3.mysql是非常优秀的数据库，其本身查询所消耗的时间，视代码而定，一般都很少，如0.0几秒等，但实际上因为mysql工作载荷如同时查询数等等，你可以看到wp的每个查询都会消耗0点几秒的。这点下篇文章中将会指出。对否，可以讨论下哦。呵呵。

7.2008.07.26.9:15.pm. oyster: wp 本身是有缓存机制的，但是很多插件在使用时为图方便就没有按机制来所以就造成了一些问题。这里我还要纠正一些错误观念。 ------------ 5Dianso 2008.07.26 Saturday 11:35 am 我十几个widget都保存到数据库了,肯定每次都需要查询,效率很低了 ---------- 就是这种概念，访问数据库并不会直接造成速度的慢。 mysql 是世界数据库系统中排前5的了，相信设计得当，处理上亿数据级的都是没有问题的。。整的来说访问内存即缓存速度是最快的但是内存是有限，接下来是虚拟内存，即硬盘的分页区。但是他们都是有限的而且，使用的还不止你一个程序，然后就是本地文件读取跟数据库了，事实上在大数据的存取时数据库会比本地文件的读取更快。所以不要盲目迷信数据库慢，数据库慢的原因，大多是任务多而引起排队的呵呵最后我也还没搞清楚WP的缓存机制。呵呵

6.2008.07.26.3:53.pm. 山之岚: To Dianso：widget多不见得查询数就多哦。要看看该widget是否读写数据库。

5.2008.07.26.11:35.am. Dianso: 我十几个widget都保存到数据库了,肯定每次都需要查询,效率很低了

4.2008.07.25.9:53.pm. ddkk3000: 还是用缓存？等我仔细看看。

3.2008.07.25.7:16.pm. Charles: 不错，先顶再看……

2.2008.07.25.2:25.pm. shamas: 学习中

1.2008.07.25.2:05.pm. neekey: 沙发~~~~~~~~~ WP应该自己建立一个缓存体系，并且有开关控制选择性开启，而不是依靠插件，否则只会越缓存效率越低？

WordPress数据库查询三板斧之一:WP基准页面数据库查询次数统计

山之岚 — Sun, 20 Jul 2008 12:01:06 +0000

看了下面这张抓图，你就知道我为什么要做这个统计了。

昨晚上在DH的Panel里面查看站点运行情况报告，真可谓，不看不知道，一看吓一跳。竟然看到里面报告19日当日的数据库连接高达6000多次，数据库查询多达19万次。由于报告中的日期并不连续，少了16，17和18的数据。所以我估计19日的数据可能是这几天数据利用情况的合计值吧。以15日为例，当日的连接次数和查询次数也分别高达2607和78922。所以且不管这是当日统计或是多日的合计，总之，给我一个印象就是一个字，多。

其实早在去年就和风暴轻狂聊过这个Wordpress数据库查询次数过多的问题，在去年11月写wp_list_posts这个小插件的时候，曾提到调用一次WP内置的get_permalink()都会产生一次数据查询，而其实在一个WP的Loop内，由于已经将post相关的参数如id，postname等都预读取了，没有必要（视永久链接结构而定）在模板中再次调用get_permalink()来生成永久链接。毋庸置疑，WP是个很优秀的个人博客发布平台，其内置了相当丰富的模板函数（Template Tag）用于模板制作，最大的优点就是开放API接口（Hook）支持用户自定义操作（通过插件）以实现各样功能。简单地以建房为例子来说，WP就好比是提供了一个未装修的房子框架，建好WP后，用户直接就可以入住了。各式各样的模板就好比如是装潢设计，各种插件好比是具有一定功能的家具或电器等。如果你对其不了解，直接选择最普通的、千篇一律的设计（使用默认模板），直接也可以使用。如果你想把自己的家弄得有个性，就可以利用WP的内置函数来设计模板，为了使小家更舒适更愉快，你可以挂上一些特定插件来实现。夏天到了，你可能会挂空调，冬天用暖气。而Widget提供了一个捷径给用户以实现其自定义功能。所以如果为了保证其考虑到不同用户的使用情况，WP会强调其标准化。然则东西一旦做大做泛了，其兼容性自然难以保证。很容易产生了WP和插件，以及版本，数据库等之间的兼容性问题。这里的兼容性很大程度上并不单单是说WP和用户平台等之间的兼容性，各个插件之间因不兼容存在的问题更多的。很简单，你在房子里面东西加载了一大堆，虽然东西是按房子标准建立或加载的，但做东西的人不见得会考虑对其它产品的交叉影响，且作为用户也很难考虑到各个东西是否能一起使用，也就是这个道理了。实际上WP本身，若不是去接触其内核的话，仅仅是想做到自己做模板设计的话，还是很简单的，用户甚至不必对php有太深的了解。只需要通过了解一些简单的操作如变量定义，流程控制以及熟悉WP内置的模板函数调用就可以了，还有基本Html和css知识，就可以制作出自己心仪的模板了。若是想深入了解的话，就应该去接触WP的运行流程，Hook，数据库结构以及rewrite rule等等。

回到数据库查询吧。ThinkAgain现用的这个Multi Color模板，从首页到文章页，以及页面页等，大概数据查询次数在30-40次之间，视使用不同插件，查询次数会有些差异。如我将文章页中的上下文章导航禁用，可以少了4次数据查询。将侧边栏（主要调用了评论和最新文章目录等）关闭，会少7个查询。将get_permalink关闭可以少1次，移到wp_link_page也可以少1次查询等等。关闭评论也可以少1次查询。关闭下面相关文章推荐，竟然可以少了10个查询。

在具体进入测试之前，先介绍下统计WP数据查询次数的函数：

，用来显示该页面的数据库查询次数。

因为各个模板加载的函数等都不同，所以为了使得数据有可参照性，我在本地新建了WP2.51和WP2.6版本的2个博客用于测试。2个博客分别加载默认模板，禁用所有插件。采用默认Widge，各发布了6个文章和3个页面，将首页显示文章数改为3，用于翻页函数的查询。测试发现，WP2.6的查询次数竟然比2.51少了3次。可见升级的好处还不少吧。在此将WP2.6和WP2.51的结果放出来。显示格式为，测试页面：查询次数（WP2.6，WP2.51）。

首页: 18次，21次

文章页: 15次, 18次

页面页: 17次，20次

目录页: 16次，19次

时间存档页：16次，19次

标签页: 17次，20次

搜索页：16次，19次

404页：10次，13次。

自定义页面页（加载自定义页面模板）：9次。注，自定义页面模板内置查询次数的函数代码。

对比看来，实际上我们在用的模板比默认模板的查询次数多了好多。当然这些主要是一些插件造成的。如在侧边栏调用最新评论等。

下面来具体看看一些常用函数需要多少个数据库查询。分别将index.php（首页），single.php（文章页）和page.php（页面页）代码全部清空，测试其加载页面的数据库查询次数，结果有点结舌。

空白index.php：10次，13次

空白single.php：9次，12次

空白page.php: 9次，12次。

仅加载一个页面就需要这么多次数据库查询。汗，这效率可不见得高。记得风暴轻狂曾给我说过discuz似乎只用4个查询。接着以WP2.6默认模板的首页为例，我们来分析下，是什么功能消耗了这些数据库查询。

关闭加载Header数据库查询为15次，即少了3次数据查询。可Header里面仅仅是调用bloginfo()以及get_option()，WP对这些变量都进行缓存了，调用这些语句是不会发生数据库查询的，那么消耗3次数据库查询的是何方神圣呢？答案是：，这个语句是实际上是一个WP Hook，提供了一个接口给一些需要调用数据库数据在页面头部写代码的插件。插件是通过：

add_action(‘wp_head’, ‘函数名称’);

来将代码插入头部的，如插件运行需要的css文件地址或需要加载的js地址等。所以这个接口消耗的数据库查询数，应该是和使用插件的个数有关。默认是消耗3个。用于添加Nofollow（如果选择禁止搜索引擎抓取博客的话），EditUrl和wlwmanifest，前者是用于标识博客RPC发布网址，后者应该是为Windows Live Writer专用的接口wlwmanifest.xml的绝对地址。

同样位于footer的和sideba的视插件而定，也可能会消耗查询。默认模板下是没有消耗查询数据。

关闭加载Sidebar（侧边栏）的查询次数为13次，也就是少了5次查询。其中wp_list_pages和wp_get_archives各消耗1次，而wp_list_bookmarks会产生2次查询。还有1次的查询是wp_register()造成的。wp_register()是用来生成注册按钮（如果选择用户可注册时，用户浏览时显示）或显示Site Admin（管理者浏览时显示）。

而以上就是WP2.6在默认模板下的数据库查询次数及其消耗情况。而为什么加载一个空白页面也需要那么多数据库查询的答案也就出来了，也就是即使模板中没有加任何代码，但是WP在运行时已经默认通过地址解析等到的参数来判断是否是首页或页面，文章页等，自动查询了数据库以加载资料，这些东西都被存放在$post等全局变量里面。

在简单分析下single.php的数据库查询消耗情况，previous_post_link和next_post_link各消耗1次。comments_template();消耗1次。仅次而已。

汇总下，仅列出WP2.6的数据，

首页: 18次，文章页: 15次, 页面页: 17次，目录页: 16次，时间存档页：16次，标签页: 17次，搜索页：16次，404页：10次。

wp_list_pages，wp_get_archives，wp_register，previous_post_link，next_post_link，comments_template这些函数各消耗1次。

wp_list_bookmarks消耗2次查询。

从对比上看，很明显WP在2.6版中对数据库查询等方面做了改进，估计可能是在和post相关的方面，这些等对比完代码后，再发上来。当然最重要的是如何减少这些数据库查询，这些也得等个人调试顺利后，慢慢再总结吧。

评论12:

12.2008.08.01.2:23.pm. ddkk3000: “曾提到调用一次WP内置的get_permalink()都会产生一次数据查询，而其实在一个WP的Loop内”——怎么没说明怎么修改呢。

11.2008.07.23.9:06.pm. 山之岚: To mygtd，呵呵，那敢情好啊。自己做的php blog，这样才最爽，因为什么部分该怎么修改或改进等，都可以自由掌握。

10.2008.07.23.8:53.pm. mygtd: 我不是用WP的，只是自己做PHP站的BLOG

9.2008.07.22.2:32.pm. 山之岚: @oyster: 没有好的wp技术文档？推荐你一个吧。http://codex.wordpress.org/Developer_Documentation 。我的绝大部分WP方面的知识都是从这里来的。

8.2008.07.22.1:53.pm. oyster: 没有一个好的wordpress技术文档我查的几个都很不完整.内容还是需要自己再努力去找源头.呵呵

7.2008.07.21.7:29.pm. ddkk3000: @山之岚呵呵，除万非得以，才静态。你现在的博客访问速度比原来在bh（或是hm）上，快多了。把服务器搞的更快是加速的硬道理。 @shamas 你那个查询次数，并不是每次访问时的，而是深层时的，所以没有关系。

6.2008.07.21.4:07.pm. 山之岚: @shamas: 生成静态的话，是不存在数据库查询问题的。只是生成静态文件有利有弊，如由于是读取实际存在的文件，不需php解释和数据库查询，加载页面的速度固然会加快，但是如果你在页面上加载一些效果，如显示页面浏览数，以及涉及url rewrite的，如和一些下载插件存在冲突等，这些问题就会浮出来的。

5.2008.07.21.4:00.pm. shamas: 我现在虽然生成了静态,不过调用也一样高

4.2008.07.21.11:47.am. 山之岚: @ddkk3000: 严格地说，少了3次，已经不少了。如以加载空白页面为例计算，已经是降低了30%的查询了。可以想象，如果一个博客访问量大的话，这性能差距就不少了。至于2.6是否被慢？我倒是没有察觉出来。呵呵

3.2008.07.21.10:37.am. ddkk3000: 少几次意义不大，我感觉2.6比以前的版本慢。

2.2008.07.20.9:35.pm. 山之岚: @yixia: 我测试的是少了3次。估计都是和post相关方面的。等对比下代码看了再说，没有调查就没有发言权。呵呵。

1.2008.07.20.9:32.pm. yixia: 我也发现2.6是比2.51少了两次查询，呵呵