闲来无事，把这个blog的风格修改修改了。清单的口味产生了审美疲劳，决定尝试重口味了。

本次改版坚持一下几个原则：

1. 精简CSS和Javascript
2. 采用google的ajax库，让页面载入速度更快；
3. 统一化编写模板方便移植，也就是说方便共享出来，这样朋友就不会以为我吝啬而不共享风格了；
4. 便于扩展，这就是为什么把google ajax集成进来的原因；

呵呵，摆弄摆弄，争取一周之后放出来共享！

对了，目前肯定还有问题，各位朋友如发现问题请帮忙留言，或者给我email，吾将感激不尽！

感谢bluehost的CPU限制，让我对SQL查询的效率进行无限的追求。这两天CPU老是超标，我仔细查看了日志，我的这个bloggermap也他的一份“功劳”，特别是RSS阅读那一块，一个查询就占据了6秒，再加上其他几个合租伙伴的“功劳”（已经给他们发送邮件），很容易就超过30s了，所以今天晚上回来继续优化。

首先我们来看看这段关于MySQL查询的分析

# Query_time: 4 Lock_time: 0 Rows_sent: 10 Rows_examined: 74584
use sevtiger_bloggermap;
SELECT sample_blogs.id blogid,
sample_blogs.url blogurl,
sample_blogs.feedurl feedurl,
sample_blogs.name blogname,
sample_article.id id,
sample_article.title title,
sample_article.content content,
sample_article.description description,
sample_article.link link,
sample_article.author author,
sample_article.timestamp timestamp
FROM sample_article LEFT JOIN sample_blogs ON sample_blogs.id = sample_article.blogid WHERE 1 ORDER BY sample_article.timestamp DESC LIMIT 17800,10

整个查询耗时4秒，查询涉及到的行数有74584，实际输出10行，我们可以看到，整个查询的效率并不高。 (read on …)

曾经一度想放弃bluehost，主要的原因是因为“长城”、越来越差的服务器和响应速度不断变慢的livechat（当然这都是oversell的结果），然而在盛会之后，我发现bluehost的响应速度和SSH的稳定性第一次破天荒的超过了dreamhost，于是又有回归bluehost的想法了。

但是bluehost的CPU超标又严重困扰着我，熟悉storyday的朋友可能都知道，我用的bluehost基本都是几个人分享的，所以CPU超标是难免的。当然CPU的控制对于任何一个虚拟主机商来说都是很有必要的，国外知名的虚拟主机如bluehost、hostgator、MT都有严格的CPU限制，这也是虚拟主机能稳定运行的一个保证，如果你是真正的想做一个站点，就用这样的主机，如果是采集站点，还是用其他的主机，如所谓的全能主机吧，否则频繁的CPU超标会让你严重不爽。当然即使是正规的站点，也会出现CPU超标的问题，那么我们就应该考虑优化自己的程序了。

虚拟主机的CPU超标的判断一般都是根据mysql执行时间来计算的，如果一分钟之内，所有的mysql查询执行时间超过了30秒，那么CPU就出现超标，网站将会在接下来的一分钟之内被挂起，所以要解决超标的问题，就应该从Mysql查询开始，下面我从3个方面来谈谈如何优化，仅供大家参考：

1. 静态化你的站点。这个不用多说，我们都知道，静态化的页面对服务器的影响是最小的（当然我这里说得不是urlrewrite伪静态，发现很多朋友把这种方式也称之为静态，好像有点不妥），如果你使用wordpress，可以使用 cos-html-cache来进行静态化；
2. 优化MySQL查询。在mysql查询中，尽量使用索引，这样能大大的提高Mysql查询速度。如果数据过多，就算使用limit 100000,10这样的限制查询，即使获取的数据只有10条，执行的时间也会变得很慢，那么这个时候就得考虑查询的精准化了，可以采用其他条件限制mysql遍历整个数据表；
3. 使用google或者百度的站内搜索。很多web程序，在搜索的时候使用的都是类似” SELECT * FROM table where content like ‘%西洋美女%’;”的SQL语句进行查询的，而这种查询往往是最消耗时间的。SQL会对整个数据表进行遍历，遍历的时候还得要处理content中的字符，它使用的时间一般会是” SELECT * FROM table WHERE 1″ 这样语句的数十倍到上百倍，所以站内搜索，建议采用google等搜索引擎提供的接口，如本站的站内搜索。一方面这样的方式节约了服务器的负载，另外一方面这样的搜索反而更加精准。

优化的方法多种多样，我这里暂时只列举上面3条，其他的欢迎大家补充，不过storyday还是强烈建议你静态化你的网站，如果缓存的命中率比较高的话，静态化带来的只有好处，想好了么，或许你的blog也需要缓存？

bluehost真是好啊，为了防止BH超标，我不得不努力改进SQL查询，不得不努力提高缓存的命中率，也不得不把部分占用SQL查询时间的脚本搬到dreamhost上！

看来，应该继续加深学习数据库的知识了，合理设置index是很有必要的了，要不将无法处理日益增长的数据了，尽量不用like查询，否则轻易都能占据10秒以上的时间。4万多条的数据如果查询不当很容易导致SQL运行时间过长的，其实别说是4万多条，即使部分朋友的blog才几千条数据，由于查询不当就轻易的能占据7 8秒的时间，看来优化SQL查询是一个比较长期而艰巨的任务了。

当然，目前的优化方向只有两个：缓存和优化SQL，缓存是基于PHP端，目前在bloggermap.org上已经做足了缓存，那么下一步就是优化SQL查询了，特别是对于limit begin,per之类的查询更是如此！

我用的代码高亮插件都是geshi,这个插件比较好，采用PEAR的formatter和coolcode相比，不用专门的标签，支持wp的原生态<code></code>格式的标签，所以一直以来都没有替换他。

但是这个插件有个缺点，那就是格式转换是在php端进行的，输入的代码非常的臃肿，并且也不方便复制，除非专门写javascript采用innerText来获取。所以很早就想对这个高亮重新处理。那么今天，我决定将我新处理的方式写成wp插件进行发布，这个插件的特点是对服务器的数据不做任何处理，仅仅在页面用javascript优化。所以在html源代码中甚至可以看到你的code原样。

插件下载地址：code-highlighter

特别鸣谢：http://code.google.com/p/samaxesjs/

本来是可以直接集成在模板中，但是考虑到某些朋友不愿意修改模板，所以弄成插件进行发布了！js的代码已经gzip压缩，文件大小由原来的42k降低到12k，希望不会影响到页面的载入速度。

补充，如果发现代码的半角标点被替换成全角标点，那么就是wordpress的formatting在作怪，修改wp-includes/formatting.php，把下面这一行给它注释掉：

// regular expressions
//$curl = preg_replace($dynamic_characters, $dynamic_replacements, $curl);

对了，顺祝大家中秋节愉快！
补充：测试样式表bug

补充（2008-09-16 11：30），看来仅仅特别感谢不够，有必要补充下面的内容：
此插件并非原创，它基于：

1. http://code.google.com/p/samaxesjs/ or http://code.google.com/p/syntaxhighlighter/（看到留言，原来这个js高亮度代码还有另外一个主人。这两者之间什么关系啊，我彻底迷惑了，看样子好像是后者原创，但是我这个插件的JS来自前一个链接，高亮的JS版权，让他们自己去争吵吧，总之，感谢高亮JS的作者）
2. php；
3. wordpress；
4. html；
5. javascript；

另外，插件的原创和插件使用到脚本的原创没有必然关系吧，就如同1bloggerchache一样，人家使用了我的代码，但是他确实是原创。无所谓，是不是原创丝毫不影响我，你说不是便不是，我做的仅仅是让高亮的代码以插件的方式嵌入到WP的风格中，使之使用起来更加简单，然后在这个blog上分享而已。

真是搞笑，还分享过毛线啊！

今天升级wordpress，发现wordpress推荐的这篇文章介绍得相当好，于是乎打算翻（主要是根据个人理解翻）译过来，虽然本人在不经意过程中几乎都将这样的漏洞给过滤掉了，但是还是不能掉以轻心。

SQL注入攻击一直都在被广泛的讨论，然而人们却忽略了今天我将要介绍的这两个安全隐患，那就是超长SQL查询和单列SQL字符长度限制可能会带来的问题。

首先我们来谈论一下超长SQL查询

max_packet_size

这个东西是用来限制mysql客户端和服务器通信数据包的长度的，比如一个查询为“select * from user where 1”,那么这个长度仅仅几十个字节，所以不会超标。在绝大多情况下，我们很难会超过mysql的默认限制1M（可以想象一下，1M的SQL语句还是很长的）。这里插一句，看到这篇文章之后，我终于清楚我当初用PEAR DB 的INSERT插入数据失败的原因了，很可能就是数据长度超标。对于MySQL来说，如果查询字符串的大小超过了这个限制，mysql将不会执行任何查询操作

如果访问者有可能控制你的sql长度，那么你的程序可能会受到攻击。哪些情况访问者可能控制sql的长度呢，比如不限制关键字长度的搜索。还有可能就是你的程序如果要将用户的登录作为日志启用，总之凡是涉及到超长sql查询的地方，一定得小心检查自己的sql，防止超长而查询失效。不过说实在的，本人认为这个问题倒不是多大，数据库光里管理员也可以自行设置MySQL的max_packet_size的长度，或者在处理可能超长的SQL查询的时候做一个长度判断。

MySQL列长度限制

这个是本文的重点。MySQL对于插入的字符串，如果长度超过了数据表限制的长度，MySQL将会截取前面部分字符串插入数据库中，而不会将错误报给web程序。对于粗心的程序员，这个问题可能会导致程序的漏洞，其实目前的wordpress有很多限制，通过这个漏洞攻击应该没有任何作用。下面是原作者的几个假设，如果同时满足这几个条件，获取一个站点的用户名是相当容易的事情，幸运的是目前的wordpress并不太可能会同时满足下面的条件：

• 该web应用允许用户注册（开放注册的wordpress满足此条件）；
• 超级管理员的用户名已知的，比如admin，这样方便攻击者寻找目标（可怜wordpress也满足）
• MySQL使用的是默认的配置（估计大多数都满足）
• 注册新用户的时候，程序没有对用户名的长度给予限制（我测试过，wordpress也满足）
• 用户名被限制在16个字符（这个和上面的没有关系，仅仅是方便举例）

下面我们来看看攻击者是怎么攻击的：

首先攻击者用已知的超级管理员id如admin注册，那么这个时候程序就会用

SELECT * FROM user WHERE username='admin '

按照以前的习惯，该插件的名字叫做：cos_visitor_comment。

插件功能：根据cookie，显示当前访问blog访客的历史留言，方便访客查看、检查。

插件实现：基于ajax，所以即使页面全部静态化也可以正常使用

安装方法：上传插件-》激活插件-》修改模板。在需要的显示访客留言的地方，插入如下代码
< ?php show_visitor_comment(5,50,"我的评论");?>
5表示只显示最近5条，50表示字数从第50个开始切断，“我的评论”则是该部分的标题，还不清楚的朋友，改变上面几个参数看看就知道了。

css美化：html结构如下，熟悉css的自行美化

下面是CSS示例，修改成你需要的样式，添加到模板文件的css中（本人喜欢集中处理，所以这个插件没有另行增加css）
ul#visitor_cmt{
padding:3px;margin:3px;border:1px solid #ccc;width:100px;
/*整个ul的风格*/
}
ul#visitor_cmt li{
list-style:none;/*不显示list的默认黑点*/
}
li.li-1{color:red;/*交替颜色*/}
li.li-0{color:green;/*交替颜色*/}
ul#visitor_cmt li.vc_title{/*修饰标题*/
font-size:120%;
font-weight:bold;color:Red;list-style:none;
}

有朋友问过几次本站的“我的留言”是如何实现的，所以干脆花点时间整一个插件送给你们，喜欢的就下载用吧，有问题的就请留言哈。
对了，下载地址在这里cos_visitor_comment(一定得把下载地址放在最后，否则某些小弟弟又不看说明，然后问出一大堆重复的问题出来)

cos_visitor_comment(支持wordpress3.0)

幸亏当初设计的时候用了PEAR的 Cache_lite做了多级的缓存。结果今天进入google统计一看，没有想到今天居然飙升到13000多IP，实在不可思议，估计又是撞上了新的热门关键词语，看来改版的时候得更加注意考虑缓存了，缓存设计至关重要，否则很容易被拖垮的。目前新的版本已经完成了50%，希望能在6月之前发布出来！