我不用租房子，不用攒钱买房子。

按理说，稍微努力找个好点的工作，做个月光族挺好。

再找个北京女孩，谈几年恋爱，结婚生子，享受小资生活，真挺好。

有句俗话：老婆孩子热炕头，也许就是对这种生活的简单总结。

我喜欢另一种有点像童话的故事。

2006年大学毕业，小强和小娟，一起从外地来到北京。看着最低 2W 起价的房子，两个人一起低下了头。以他们的收入，只能在南四环外某居民区租下一间10平米的小屋子。用攒了2个月的工资付完租金后，他们一起来到小区门口的成都小吃，每人吃了一碗牛肉面。回到刚租到小家里，小强对小娟说：“相信我，几年以后，我会赚到钱，买一套属于我们自己的房子。到时候，我们就结婚吧，你愿意嫁给我吗？”小娟看着小强那坚定的眼神，幸福地点头答应。

从那以后，是漫长的平淡而艰苦的生活。在这10平米的小屋子里，有掉皮的墙，有破损的小写字台，有窄窄的小双人床；有欢笑，有哭泣；有甜言蜜语，也有争吵不休。

但自始至终，一直陪伴他们的，是那份追逐梦想的信念！

她能看到的，是每天写程序到深夜的坚持不懈的他。

他能看到的，是每天给予关心支持的不离不弃的她。

幸运的是，经过 4 年的艰苦努力，小强的付出，终于有所回报。

两个人靠自己的努力，攒下了郊区一套一居室小户型的首付款，他们终于实现了自己的梦想。

小强实现了 4 年前的诺言，小娟也如约答应了小强的求婚，他们终于开始了自己的幸福。

本来，这是个喜剧式的结尾，到此可以结束了。

我要继续写完这个故事：小强的踏实努力的性格，让他在事业上的发展如日中天。没过几年，他们的经济实力不仅超越了小康小资，更是达到了中产阶级水平。但是，小强并没有像大多数事业有成的人那样，开始勾三搭四，小三儿成群。他一直用心爱护着小娟。

我想，正是她在那最艰苦的几年中的不离不弃，彻底感动了他。他知道今日的所成事业，离不开她那份漫长而坚定的信心和支持。

他们可以一起慢慢变老，一起携手走过一辈子。

故事可以结束了。

像童话么？我想这应该是很多北漂夫妻中比较成功的案例的故事原型吧。

虽然我是北京长大的，但在我心底，一直有一个如此感人的童话爱情梦。

前一阵相关的报道很多，《三枪》还在北京电视台做了一个网游的发布晚会，在上映前造足了气势，把大家的胃口吊得很足，看样子这回《三枪》一定能创造新的票房奇迹。

原本计划看《2012》的，不过正好赶上《三枪》上映，觉得大腕儿派张艺谋 + 演技派孙红雷 + 人气派小沈阳 + 搞笑派闫妮，能给我带来足够精彩的 90 分钟。

然而，看完后，对这部以喜剧标榜的年末贺岁电影，我只能用 失望 这个词来形容。

2004年，张艺谋指导的《十面埋伏》上映，我一个大学同学对此片的评语为：剧情是硬伤！

这电影我也看了，对此评语表示十分赞同！不过画面倒是觉得很漂亮。

2006年，张艺谋指导的《满城尽带黄金甲》上映，我看的是DVD，看到一半，实在看不下去了，所以至今我都不知道这电影说的是什么事儿。好像记得有人说《黄金甲》是《雷雨》这部话剧的电影版，没看过《雷雨》，不做评价。但从我没能看完整部《黄金甲》这个事实来说，剧情依然是硬伤！不过画面依然觉得很漂亮。

2008年，北京奥运会，不能再用剧情这个词了，那天正好紧急处理服务器的事儿，没看全开幕式，不过就开场的几分钟那个效果来看，我觉得真是很漂亮。

2009年，《三枪拍案惊奇》，我自己评价：剧情是硬伤！画面很棒！

简单的描述下剧情：

主线：面馆儿的老板怀疑老婆跟伙计李四私通，暗地里贿赂巡逻兵杀了这对男女，结果反被巡逻兵谋财害命；
副线：面馆儿的另外两个伙计想办法把老板拖欠的工钱偷回来，其中一个（赵六）不小心撞到巡逻兵，结果被杀；
交叉线：阴差阳错，李四发现了老板的尸体，偷走埋了，然后误打误撞地跑到伙计赵六被埋的地方大便，被巡逻兵发现踪迹；
结果：女伙计陈七提前跑路，李四被巡逻兵一箭穿心，巡逻兵被老板娘一枪毙命，电影结束。

我觉得一个故事，通常要表达出一个主题。

婚外情会导致灭门惨案？夸张了点吧？如果不是这个主题，我看不懂这个故事想说什么。

从喜剧的角度看，我觉得可乐的地方不多。可能我的笑点不够低。大部分可以被称之为笑点的地方，感觉都是生硬地套用网络流行语，或者重复小沈阳的招牌语调。

对于每天有很多时间在网上看转贴的我来说，见到这些笑点的次数太多，没有可乐的感觉了。

很多包袱都有东北二人转的味道，我不太喜欢二人转，因此更觉得不可乐。

相比之下，我还是喜欢《非诚勿扰》的京味儿冯氏幽默，那些台词让葛大爷说出来最正宗，最好玩儿。

回到剧情，剧情里稍微有些让我感兴趣的地方，就是在杀人之后，发生的一些巧合或者说是误会，让我看出了一点《疯狂的石头》和《疯狂的赛车》的感觉。

可惜这感觉刚开始没几分钟，电影就结束了。

总之，从剧情和喜剧效果来说，我给《三枪》的评价是：差。

说说好的地方。

画面和场景，非常棒！评价是：优。

室外开阔地：拍摄地点好像是西北的戈壁一带，橙黄色的山体和土地，在清澈的蓝天白云下，给我一种清净透亮的感觉。
房屋和院子：老屋子，老砖，老墙，老马车，还有对方的瓦片和零碎，感觉物品丰富，很充实。
室内：老饭碗，老柜子，老木头，老桌子，老板凳，老床，老窗户，特有饱经岁月的味道，颜色很入眼。
过度场景：在一片戈壁山上，用固定的角度，记录太阳下山到月亮上山过程中，云层的移动、阴影的移动、光线的转变和月亮的轨迹，很漂亮。

再简单说说音效，可能我很少去电影院看电影吧，感觉音效很不错，尤其是刚开场的三声枪响，吓了我一跳，清脆 + 震撼。稍微遗憾的是，这电影音效不是卖点……

说到卖点了，我看，真正的卖点就是导演和演员。

张艺谋：奥运 + 图兰朵 + 60 周年大庆。
孙红雷：电视剧《潜伏》。
小沈阳：09 年央视春晚和北京台春晚。
其他演员我不太了解，就不说了。

据说电影投资了一个亿，在影片的大部分时间里，只是 6 位演员转来转去，拍摄成本应该很低。倒是结束后，多人集体 MV 加上孙红雷的热舞颇有看点，我不知道是不是 MV 的拍摄成本比主要剧情还高？拍摄成本 + 演员的固定片酬应该不高，估计 3000 万够了，其他成本，都用在宣传和广告上面了吧？

也许我是妄加猜疑，在宣传造势上花这么大成本，是不是为了弥补影片在剧情和喜剧创意上的不足？反正我记得《非诚勿扰》，我是听朋友说很逗才去看的，没见太多广告。

晚上看首都经济报道，新画面董事长张伟平说了一句：“我敢说80%的观众到电影院是去看热闹的，不是看演技的。”

我又想了想，还真挺对的。我看《三枪》，不是因为它是喜剧，而是因为张艺谋、孙红雷和小沈阳，我是来看热闹的。

所以，我说，你想看热闹，我很推荐《三枪》，如果你想看剧情和喜剧效果，《三枪》会让你失望。

完。

警察叔叔说，网上很黄很暴力，我却很傻很天真，不让我再看到我最爱的网站

直到有一天，一个无辜的小鸟被无情地封杀，我才意识到问题的严重性

面对河蟹坚硬的钳子，小鸟不能改变什么，唯一能做的，就是送上几句脱口秀解解气

据说那个墙，又黑又高，看到朋友们发来的结构图，我哭了

我再也看不见可爱的 Twitter 小鸟了么？

...

...

...

直到有一天，听到 Leakon 发出怒吼！

他说他能帮我穿过那道墙！

于是我认真地记下了他说的方法：

1. 去淘宝买 VPN ，要买带 SSL 加密的，尽量提供多个 IP ，没办法，穿墙总要花点钱
2. 改用 OpenDNS （208.67.222.222 和 208.67.220.220），因为墙内的 DNS 就是不告诉你 IP
3. 用 VMware 装 XP，XP 负责 VPN 拨号，注意 DNS 用 OpenDNS 的那 2 个 IP
4. 在 XP 上装 CCProxy 作为代理服务器
5. 使用 Firefox + FoxyProxy，把代理地址设为 XP 的 IP，FoxyProxy 可仅对域名白名单中的网站使用代理

这是 Leakon 在 09 岁末为大家即兴创作的一个 2 分钟小剧本，希望大家喜欢。

谢谢观赏

本来，在 html 中写入 IFrame 标签，并加上 allowTransparent="true" 这样的属性，IE 也一样可以透明，但今天的问题是必须用 Javascript 插入。

用 IE Developer ToolBar 测试，在 IFrame 的 src 页面的 body 样式上加上 backgroud:transparent 可以使 IFrame 透明。

但我们要用 Javascript，本域的 Javascript 脚本是没法设置跨域 IFrame 页面的，况且创建 IFrame 的时候还没设置 src，所以这个办法不行。

只能用个土办法，把 src 设置为一个绝对路径的 html 页面，这个页面你自己可以任意编辑，把 body 的样式设成透明即可。

注意，为了性能，只在 IE 浏览器下设置 src，Firefox 和 Chrome 都不用设置。

在这一点上，IE7 跟 IE6 一样弱，比现代浏览器差远了！

这样的做法太笨了，有很多缺点：

1. 浪费带宽，文件也许很大
2. 文件无用，下载回来也无法分析文件内容

怎么解决？

看浏览器会发送 Accept 指令，告诉服务器可接受的内容类型，但这不能阻止服务器返回不接受的内容，即哪怕请求的资源不在 Accept 列表中，仍然会把文件返回给客户端。

这方法不行。

想着，有没有办法，在得到服务器 response 的时候先分析 header，如果不是可接受的类型，就断掉连接，不必下载后续内容？

如果用 fsockopen 写的网络通讯接口，这一点很好实现。但 CUrl 怎么控制？

仔细看文档，找到一个选项 CURLOPT_HEADERFUNCTION。

这个选项要给一个回调函数作为参数，回调函数相当于一个触发器，CUrl 会把每一条 response 的 header 指令传给这个函数，由函数来决定如何执行后面的步骤。

回调函数要定义 2 个参数，第 1 个是 CUrl 的资源标识符，第 2 个是单独的一条 header 字符串。

如果想让 CUrl 继续下载后续内容，那么回调函数应该返回 header 字符串的长度：

return strlen($strOneHeader);

如果不想继续下载，直接返回数字 0，那么 CUrl 就会发送 TCP 的终止连接的指令，不会继续下载后续内容了。

加上这个触发器，经过测试，我的小蜘蛛可以成功地忽略非 text/html 类型的文件，大大加快了抓取速度，避免了很多问题！

小提示，给 CURLOPT_HEADERFUNCTION 设置回调函数的时候，文档上说要一个字符串形式的函数名作为参数。

这不准确。

实际上 PHP 可以指定任意类型的回调函数，可以是纯函数、类的静态方法和对象的方法：

• 纯函数：$callback = 'my_callback_func';
• 类常量：$callback = array('NAME_OF_CLASS', 'nameOfMethod');
• 对象方法：$callback = array($object, 'publicMethod');

完。

正则表达式和查找的 needle 字符，都是用字符加引号直接作为参数传递给上述函数，比如：

preg_match("#^http[s]?://#i", $strUrl);

用以匹配是否是 http 开头的 url。

记得以前看过过类常量与普通常量的性能对比，类常量快得多，在这个例子上，把字符串传给函数，是不是每次调用都是先把字符串转换成内部变量呢？如果预先定义类常量，然后以常量为参数传给函数，是不是能快一点？像下面这样：

const PREG_HTTP_URL = '#^http[s]?://#i';

preg_match(self::PREG_HTTP_URL, $strUrl);

两种方式，性能肯定不一样，那种更快呢？

...

...

...

揭晓结果：

运行外层方法 50 万次各 3 次，取平均值
字符串：[31284.85]q/s    [15.98]seconds
类常量：[29175.49]q/s    [17.14]seconds

可以看到，用类常量的方式，性能不升反降！！

现在还不太理解为什么会这样。

string(1) "\"

Linux 下呢？

string(1) "/"

换个参数，dirname('/home/leakon/sofav.php')，如果你认为上面的不同，是因为 Windows 的目录分隔符是反斜线 "\"，那下面的结果如何解释？

Windows: string(12) "/home/leakon"

Linux: string(12) "/home/leakon"

再换参数，dirname('D:\Leakon\Code\sofav.php')

Windows: string(14) "D:\Leakon\Code"

Linux: string(1) "."

奇怪吧，为什么有这么大区别呢？

现在还不太清楚，提供一下我的测试环境：

Windows 下存在 D:\Leakon\Code\sofav.php 这个文件，Linux 下存在 /home/leakon/sofav.php。

等搞明白回来顶，看到的，用到的，留心记一下吧。

顺便说下，这个问题，是用单元测试发现的。

我知道很多开发者都懂单元测试，我也知道很多开发者并没有切身去实践单元测试。

在我看来，可能G.cn不想交保护费，然后某色社会，向基地组织学习，在实施罪恶之前，给出一段录像，算是恐吓。

看了cnBeta的众多评论，尤其是看到很多G粉儿的一片声讨CCAV的声势，我在些许欣慰之余，不免有些担心。

在天朝这样的国度里，最广大人民的根本利益，注定是要被黑老大们QJ的。怎奈我无力劝说所有的仍然心存良知的可爱的人们，其实你们可以在评论里一致祝福CCAV越办越好的，当黑老大们看到你们的愿望，便会搞死CCAV让你们享受“快感”。

实事求是，我也是G粉儿，我觉得很正常，痴迷于技术的人，怎会不是G粉儿？

反过来说，断章取义，唯恐世界变革影响自己的不劳而获的生活的不是G粉儿的人，怎会不是无知的SB？

前一阵看过一个介绍中国最初修建铁路历程的纪录片，给我很大感悟。那会儿全中国只有李鸿章支持修建铁路，可惜那会儿他还只是浙江巡抚，影响力有限。但在当时，算作洋务派代表的李鸿章，几乎是只身一人，面对大清国上上下下从太后到平民百姓所代表的顽固派，进行力量悬殊的斗争。

那会儿的官民倒成了一家人，说火车样子诡异，乃不祥之物，鸣音巨大，有伤风水。

像！真是惊人的相似，今天在CCAV上看到的这帮坐家们和砖家们的顽固不化的嘴脸，怎么跟200年前大清朝那帮愚昧的官民一副德性？

我正好看了谷歌中国的黑板报，引用了 Sergey Brin 的一片文字：《一座永远的图书馆》

请允许我在本文的最后全文引用这篇文字，我怕被黑老大们当大闸蟹给河蟹了。

我之前，有个梦想，把世界上所有有价值的文字、声音、影像全部记录下来，以供现在的我们和未来的人们学习、参考、回忆。

不过放眼世界，当今有能力做这件事的，也就只有谷歌了。

我只能感恩地谢谢地球那边的上帝，让 Larry Page 和 Sergey Brin 没有像天朝的企业家们一样坐拥财富之后便吃喝嫖赌抽，感谢上帝让两位天才也有了造福世界，造福后代的想法，并已经有了实际行动。

我看《明朝那些事儿》，讲到朱元璋的第四个儿子朱棣，取代朱允炆，开创永乐盛世，并修建了一部涵盖当时社会文明所有内容的《永乐大典》，这真的可以称之为前无古人，后无来者。这套书我印象中有几万卷，但后代被损，也在八国联军入侵之时被严重损毁，现今能找到的只有几十卷！看到这部分的时候我震惊了！我觉得这是中华民族文明财富的极大损失！

我很喜欢逛故宫，看完历史书，就更喜欢去故宫再看看，感觉身在其中，似乎能体会到几百年前的景象。我很遗憾，这一切只能是空想，看过所有的古装电视剧，也无法真正还原古代的社会形态。还好现在有了录音机、照相机、摄像机，可以让今天的世界，如实地展现给200年之后的人们。不过我们现在只是历史的“正在扮演者”，不能以历史的“后期观察者”身份看到古老的历史原貌。

呵呵，真是具有讽刺意味，我不知道怎么想出一个“后期观察者”这个词，看看标题，CCAV的“今日观察”，多么巧合的对比！你们那点思维，也只能今日观察，或观察今日了。

也许我东一句西一句的语言，不能让你完全明白我的意思，没关系，先让这些文字留在这里吧，日后我们回来再看，或者最好保存100年，让后代的学生当文言文要求背诵！

如果真的不明白，那么请看 Sergey Brin 的 《一座永远的图书馆》，现全文引用如下：

http://googlechinablog.com/2009/10/blog-post_20.html

一座永远的图书馆

2009年10月20日 下午 07:33:00

发表者：谢尔盖•布林（Sergey Brin）
转载自《纽约时报》

2009年10月8日，山景城，加利福尼亚

“电车没有得到普及的根本原因在于（1）生产商的失误：他们没能恰当地向大众宣传电车的实用性；（2）电力公司的失误：他们没能提供足够多的充电站和变压站，让人们更为方便地拥有和使用电车。早期电车在速度、行驶里程和实用性上的限制给人们的印象至今依然存在。”

这 个引述一点也不会让那些了解电车的人感到吃惊。不过，如果这些话是在一个世纪之前听到的，那时电车年产量仅有几千或上万辆的时候，可能就会有些惊人了。这 是出现在1916年的一本杂志《电气世界》（Electrical World）某期上的一个议题，是我在可供人们搜索上千万本图书的资料馆——“谷歌图书（Google Books）”上找到的。关于当代的一个问题要回顾几百年来探讨，看似很奇怪，但是我常常觉得过去对于未来有着极为宝贵的借鉴意义。在这里，我很幸运—— 20世纪早期，关于电车的研究和记载非常广泛，而且有很多关于这一主题的书可供选择。因为1923年之前出版的书都是公开的，我很容易查看到它们。

但 是人类已经撰写的绝大多数图书并不是每个人都可以得到的，除非是那些在一流学术图书馆（premier academic libraries）中执着工作的研究人员。1923年之后所著的书籍很快消失在图书馆“黑洞”。除了个别特例，读者只能在图书出版销售的几年之内买到这 些书，之后，只能在少数图书馆、二手书店找到它们。再往后，随着岁月流逝，合约被丢弃了、遗忘了，作家、出版商消失了、不见了，版权所有者的踪迹也难以寻 觅。

不可避免地，仅存的几本书也只能慢慢腐化，或者在大火、洪水或其他灾害中失踪。1998年我在斯坦福大学的时候，洪水损害、毁坏了上 万本图书。不幸的是，这样的事时常发生——一场类似的洪水20年前就曾在斯坦福发生过。你可以在1980年出版的《斯坦福-洛克希德•迈耶图书馆洪水报 告》（The Stanford-Lockheed Meyer Library Flood Report）中读到这段经历，但是这本书再也找不到了。

图 书是世界共有知识、文化遗产的重要组成部分，因此谷歌联合创始人拉里•佩奇（Larry Page）在10年前就首先提出了将所有书籍数字化的建议，那时的谷歌还是一家羽翼尚未丰满的新公司。那时，这项工程看起来如此狂妄自大、充满挑战，我们 无法吸引人们加入进来。但是五年以后，也就是2004年，“谷歌图书”（Google Books）（当时被称作Google Print）诞生了，可以让用户搜索到几十万本图书。今天，这个数字已经超过了一千万，并且仍在增加。

次年，我们受到了美国作家协会 （Authors Guild）和美国出版商协会（Association of American Publishers）对于这个项目的起诉。虽然我们之间有分歧，但却也拥有共同的目标，那就是打开禁锢在无数绝版书籍中的智慧，当然也会公平地对版权所 有人进行补偿。于是，我们共同努力达成了和解，以实现我们的共同目标。这一协议旨在让图书作者、出版商和谷歌实现共赢，不过实际上真正的赢家是那些能够获 得一片极为宽广的书籍天空的广大读者们。

这一协议也是颇受争议的，很多团体都积极发表意见，褒贬皆有。我想借此机会来澄清关于协议的一些 事宜，并且说明我对这个计划感到自豪的原因。这项协议旨在让成百上千万绝版但受版权保护的书籍“复生” ，或者会对读者收取一定费用，或者在广告支持下免费，但是大多数收入会归版权持有人，无论是作者还是出版商。

有些人说这个协议类似一种强 制许可证，就像集体诉讼和解一样，如果会员在某一规定日期之前不提出退出，那么该协议将对所有会员有效。而事实是，版权所有人可以在任何时候设定图书价格 及访问权或者从“谷歌图书”退出。对于那些版权所有人尚未出现的图书，将会为其制定合理的默认价格和访问规则。这既让读者能够读到尚未找到版权持有人的 “孤品”，也能为版权所有者不断累积资金，直至成为他们“不再隐身”的动力。

其他人对于协议在竞争方面的影响产生了质疑，或者断言这会限 制消费者对绝版图书的选择。事实上，这项协议根本没有限制其他公司或者组织作出类似的努力。此协议在绝版图书方面对消费者选择的限制，也只不过像是限制消 费者选择传说中的独角兽那样。如今，如果你想要得到一本绝版图书，只有一个选择——飞到美国几所一流的图书馆，并期待着能在书架上找到它。

我 希望能有一百种类似服务，那样我就能很容易地阅读到某一本书；那样将会节省很多时间，而且会为谷歌省掉很大力气。但是，尽管如今有不少数字化项目正在进行 （谷歌甚至为其他一些同类机构提供资金支持，包括国会图书馆的一些机构），但是没有一个颇具规模，造成这一现象的原因就是因为没有其他人选择为必要资源进 行投资。如果想要有一百个这样的项目，那现在至少要有这样一个服务存在。

如果“谷歌图书”成功了，其他项目也会效仿，那么他们将会有捷径 可走：这个协议创立了“图书版权登记簿”（books rights registry），鼓励版权持有人现身，这样其他项目将可更方便地获得许可。虽然新项目不会立即对无人认领的作品（或“孤品”）享有同等权利，但至少这 个协议为类似诉讼的和解提供了方向，而且它是“孤品”的立法先驱，谷歌一直并将继续为此提供支持。

最后，对于“谷歌图书”这一产品以及协 议中所展望的未来服务的具体几个方面还有反对的声音，包括对于文献目录信息质量、我们对于分类系统的选择以及隐私条款细节的质疑。这些都是合理的问题，作 为一家极为关注产品质量的公司，我们会不懈努力来解决这些问题，不断完善文献目录信息、改善分类方法，进一步细化我们的隐私条款。而且，如果我们不能正确 提供产品，就会被其他人取代。但有一件事可以确定：无论停止哪项进程，事情最终都不会得以解决。

我在“谷歌图书”上找到的 《1880-1881保险年鉴》（Insurance Year Book 1880-1881）中，Cornelius Walford按照时间顺序记载了几十座图书馆和几百万册图书的毁灭，他希望这样的记载能够让人们意识到做这样一些事来保存图书的必要性。亚历山大一个著 名的图书馆曾发生过三次火灾，分别在公元前48年、公元273年和公元640年，就像美国国会图书馆一样，1851年的一次大火烧毁了三分之二的藏书。

我 希望这样的毁坏永远不要再发生了，但历史证明并非如此。更重要的是，即使我们的文化遗产在世界最一流的图书馆保存得完好无损，但是如果不能让人们轻易读 到，那也形同虚设。很多公司、图书馆和组织在保存、提供20世纪藏书的工作中都发挥了作用。图书作者、出版商以及谷歌，他们共同朝着这个目标迈出了仅仅一 步，但却是非常重要的一步。让我们抓住这次机遇，不要错过！

谢尔盖•布林（Sergey Brin）是谷歌的联合创始人和技术总裁。

通常，创建一个 PDO 连接，都是 new PDO()。

在开发环境中，你只需要把上面那个语句替换成 new SofavDB_Debug_PDO() 即可。

然后，凡是通过 prepare 的 statement 执行的任何查询和修改的语句，执行时间都能记录下来。

最后，通过 SofavDB_Debug_PDO::getTimer() 就可以得到一个数组，极其方便……

当然，这个类的执行效率会有一些小小的下降，不适合用于生产环境。

源码请见 GoogleCode：

http://leakon.googlecode.com/svn/trunk/leakon/php/sofav_db/SofavDB_Debug_PDO.php

user_id 和 item_id 两个字段都是单独的 INDEX 类型的索引。

问题是如何发现的？

今天搞程序，在自己的开发环境下，打开一个简单的页面都要好长时间，不知道问题出在哪里，只发现硬盘灯闪个不停。

观察 Windows 的任务管理器，看到 mysqld-nt.exe 这个进程的 "I/O 读取字节" 高达十几 G！！！

再次测试，发现每次刷新页面，这个进程要读取几十 M 的数据。

奇了怪了，查看 SQL 语句，还有表结构，字段都建了索引了呀。

后来 EXPLAIN 了一下，看到结果是 Using where; Using filesort。

explain SELECT * FROM table_item WHERE user_id = 2 ORDER BY item_id LIMIT 0, 5

翻了 MySQL 手册，仔细看下 filesort 的说明，知道了 Using filesort 是一种速度很慢的外部排序。

不过我不理解为什么会使用 filesort 排序，WHERE 和 ORDER BY 用到的字段都是有索引的呀。

赶紧 Google，找到几篇解释 Using filesort 的文章，得到的启示就是索引定义不当，MySQL 没有用到索引。

记得以前 Chenbin 给俺们培训过 MySQL 的优化，我还参加了两次，总感觉自己了解了如何优化 MySQL，没想到这么简单的语句我都没能优化。

现在想起来一些 MySQL 的特性了。

1. 一条 SQL 语句只能使用 1 个索引 (5.0-)，MySQL 根据表的状态，选择一个它认为最好的索引用于优化查询
2. 联合索引，只能按从左到右的顺序依次使用

这 2 点刚好可以解决我的问题。

user_id 和 item_id 是 2 个索引，我的语句中，MySQL 选择了 user_id，那么 item_id 的索引没有起到任何用处，所以，当我要排序的时候，由于记录数较多，内存中的排序 buffer 满了，只能 Using filesort 进行外部排序，因此每次查询要从磁盘读取几十 M 的数据，太慢了。

修改表结构，删除 user_id 和 item_id 的 INDEX 索引，建立一个名为 user_item 的联合 UNIQUE 索引，顺序是先 user_id 后 item_id，再 EXPLAIN，这回只有 Using where 了。

再刷新页面，观察任务管理器，mysqld-nt.exe 只读取了 2K 的数据，页面咔的一下就出来了……