一直都感觉wp的效率不太行，一直没去看看到底wp那里慢了。今天有点时间就抽空让我来看看wp首页以及文章页面到底运行了哪些sql吧。

一直都是听说wp每次打开都会有大量的请求，昨天查了一下，首页有近20条的sql查询（不包括我用了memcached缓存的），文章页的话有差不多25条查询，把sql输出一下看傻了。这啥啊各种联表各种表达式。 :s1liuxue

运行wp的get_links_list()函数，监视一下sql可以看到:

SELECT *  , IF (DATE_ADD(link_updated, INTERVAL 120 MINUTE) >= NOW(), 1,0) as recently_updated  , UNIX_TIMESTAMP(link_updated) AS link_updated_f  FROM wp_links  INNER JOIN wp_term_relationships AS tr ON (wp_links.link_id = tr.object_id) INNER JOIN wp_term_taxonomy as tt ON tt.term_taxonomy_id = tr.term_taxonomy_id WHERE 1=1 AND link_visible = 'Y'  AND ( tt.term_id = 2 ) AND taxonomy = 'link_category'    ORDER BY link_name ASC

这句东西。就我现在这种小表都需要0.1秒的查询时间，表大了的话，会很搞笑的。所以各位用wp，而且有使用get_links_list()这个函数来获取友链的同学赶紧换其他方式吧。不要用这个函数了。

假如你的友链关系不复杂，像我一样没有做分类什么的，直接用下面这句就行了，不明白wp官方为什么会将link_visible这个字段采用字符型做记录，虽然建了索引但mysql跑去扫全表了。

select * from wp_links where link_visible='Y' order by link_name asc

于是从查询到显示，可以在页面上搞这么一段：

#global $wpdb;	//这应该写不写无所谓
$links_wpdb = $wpdb->get_results("select * from wp_links where link_visible='Y' order by link_name asc");

if( $links_wpdb ) {
        foreach( $links_wpdb as $k=>$v ) {
                $tmpstr .= '< li >< a title="'.$v->link_description.'" href="'.$v->link_url.'" target="'.$v->link_target.'">'.$v->link_name.'< /a >< / li >'; //注意去掉一些地方的空格
        }
        echo $tmpstr;
}

假如你的服务器安装了memcached，那么可以这样，加了缓存减少数据库压力 :s1niuyao
（更多…）