关于MySQL的一个CAST和IFNULL函数诡异问题，不明原因，记录一下，明天继续分析。
这个是WP-PostView插件的一段SQL：
SELECT p.ID, p.post_title,
IFNULL( CAST( pm.meta_value AS UNSIGNED ) , 0 ) AS views
FROM wp_posts AS p
LEFT JOIN wp_postmeta AS pm ON pm.post_id = p.ID
AND pm.meta_key = "views"
WHERE p.post_date < "2010-03-05 22:19:55"
AND p.post_status = "publish"
AND p.post_type = "post"
AND p.post_password = ""
ORDER BY views DESC LIMIT 5
在我的数据库上查询结果非常诡异：
ID post_title views
10 [论文]对简易几何机械化证明的进一步研究 9
32 页面总算基本修正好了 9
51 一个很好玩的钢琴Flash游戏 9
60 修改友情链接的排列方式 9
93 UML之父——Ivar Jacobson介紹SMART方法 9
选出来的views列全部是9，不知道为什么。
如果我去掉IFNULL，
SELECT p.ID, p.post_title,
CAST( pm.meta_value AS UNSIGNED ) AS views
FROM wp_posts AS p
LEFT JOIN wp_postmeta AS pm ON pm.post_id = p.ID
AND pm.meta_key = "views"
WHERE p.post_date < "2010-03-05 22:19:55"
AND p.post_status = "publish"
AND p.post_type = "post"
AND p.post_password = ""
ORDER BY views DESC
得到的结果将是对的，
如果去掉CAST，
SELECT p.ID, p.post_title, IFNULL( pm.meta_value, 0 ) AS views
FROM wp_posts AS p
LEFT JOIN wp_postmeta AS pm ON pm.post_id = p.ID
AND pm.meta_key = "views"
WHERE p.post_date < "2010-03-05 22:19:55"
AND p.post_status = "publish"
AND p.post_type = "post"
AND p.post_password = ""
ORDER BY views DESC LIMIT 5
得到的就是错的，并且只有2位数一下的结果，2位数以上的结果出不来，但不是9或者99了。
明天继续分析这个问题。
暂时通过去掉IFNULL来解决。
最近对我的本本（4核8线程）用top命令看系统状况出现了CPU利用率超过200%的情况，非常诧异，查了下相关资料，把这个问题弄清楚了。
首先来分析下CPU Load
load average: 0.09, 0.05, 0.01
分别是1分钟、5分钟、15分钟的平均Load。
Load这个东西怎么理解呢，就像一条马路，有N个车道，如果N个进程进入车道，那么正好一人一个，再多一辆车就占不到车道，要等有一个车空出车道。
在CPU中可以理解为CPU可以并行处理的任务数，那么就是“CPU个数 * 核数”，如果CPU Load = CPU个数 * 核数 那么就是说CPU正好满负载，再多一点，可能就要出问题了，有任务不能被及时分配处理器，那么保证性能的话，最好是小于CPU个数 * 核数 *0.7。
查看CPU核数可以通过：grep ‘model name’ /proc/cpuinfo
那么以哪个平均值为准呢？如果1分钟平均出现大于CPU个数 * 核数的情况，还不用担心，如果5分钟平均也是，那就要警惕了，15分钟平均也是这样，就要分析哪里出问题了，防范于未然
CPU利用率超过100%的问题，也是差不多，top命令应该是把每个核的CPU占用率加起来，算一个和，于是多核情况下会出现超过100%。
另外Context Switch Rate也是个非常值得注意的值，因为线程间切换的代价也是非常高的。
引用一个公式：Context Switch Rate = Interrupt Rate + TPS* N
对于一个多线程的程序，我觉得准备一个控制线程来调度任务是非常必要的，免得线程过于高并发，导致资源的争用和线程切换带来性能问题，最好控制并发的线程数基本等于CPU的总核数，减少这个N，获得更好的处理器性能。
参考了如下几篇文章：
压力测试衡量CPU的三个指标：CPU Utilization、Load Average和Context Switch Rate
理解Load Average做好压力测试
理解 Linux 的处理器负载均值
高性能服务器架构
PS. 最近博客写得少，都要长草了。顺便赞一下阿里的食堂，比我们学校食堂四年不变菜饭还贵好多了。
今天升级了Mystique主题到1.72版，原来的那个Bug又出现了，会在页面的顶头显示一段代码，查看了源码，发现是WP-PostViews Plus的代码和Mystique主题冲突了，我们来看原始输出的HTML：
/*
home blog col-2-right loggedin browser-chrome">
这不出问题才怪呢，正常的情况应该是
或者
在上面。
刨根问底，元凶指向mystique_body_class这个函数，发现在core.php文件中。
问题在哪呢？
// Special classes for BODY element when a single post
if (is_single()):
$postID = $wp_query->post->ID;
the_post();
// Adds 'single' class and class with the post ID
$c[] = 'single-post postid-' . $postID;
......
// And tada!
return $print ? print($c) : $c;
就是the_post()函数，调用the_post()时，WP-PostViews Plus的代码就被加入了，而body class= 已经输出了。
解决方法很简单，把the_post()转移到最后，就是print的下一行，这样就OK了。把这个函数里其他the_post()都删除，留一个在print的下一行就行。
