今天好晚睡啊。。

Gmail 在德国叫做 Google Mail
iPad 在中国叫做 Apple Pad

"作为一个程序员，最悲哀的时刻或最悲哀的事是什么? "

半夜一个人在电脑面前边喝咖啡边蝌蚪，一不留神把含在嘴里的咖啡勺丢到桌子上（原本想放杯子里），意识到什么东西做错了，于是 Ctrl-Z Ctrl-Z Ctrl-Z Ctrl-Z 。。。。

说明你可以随便签，反正也不用负任何责任。

社保是要交的，保障社会，至少出发点是好的。。

和男人合租，注意安全措施。。

围观大流卖身

罗马不是一天建成的！

@darasion :D

on the way home

@eric_zyh 这个是MySQL查询分析器的问题，查询分析器认为不能过滤掉85%（具体多少我也不知道，大概这个样子）的无用结果的索引不可用，所以就不使用time开头的那个索引，你如果把时间进一步精确之后去看执行计划可以看到执行计划的变化。

https://gist.github.com/1605283

我的测试环境
关系表b，500用户，每个用户关注500人，一共250000记录
信息表a，500000记录，b表每个用户500条，填充250000记录，type为0，1，2根据id mod 3更新的。

CREATE TABLE `a` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`uid` int(10) NOT NULL,
`time` datetime NOT NULL,
`type` tinyint(4) DEFAULT NULL,
`status` varchar(320) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx1` (`time`,`type`,`uid`)
) ENGINE=InnoDB AUTO_INCREMENT=500001 DEFAULT CHARSET=utf8

CREATE TABLE `b` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`uid` int(10) NOT NULL,
`reuid` int(10) NOT NULL,
PRIMARY KEY (`id`),
KEY `idx1` (`uid`,`reuid`)
) ENGINE=InnoDB AUTO_INCREMENT=250001 DEFAULT CHARSET=utf8

索引和数据全部能进入内存，索引如表结构。查下语句如下：
select sql_no_cache a.* from a,b where a.uid=b.reuid and b.uid=13 and a.time<='2012-01-11 12:36:00' and a.type=0 order by a.time desc limit 0,30;

以下过滤出全表数据越大说明过滤性越差过滤也越不精确。
当时间的过滤性达能过滤出全表数据0%-50%时查询时间基本0.01秒以下。
当时间的过滤性达能过滤出全表数据50%-62.5%时查询时间基本0.1秒左右。
当时间的过滤性达能过滤出全表数据62.5%-75%时查询时间基本0.3秒左右。
当时间的过滤性达能过滤出全表数据75%-87.5%时查询时间基本0.45秒左右。
当时间的过滤性达能过滤出全表数据87.5%-100%时查询时间基本0.6秒左右。

1. 始终要让b表结果集驱动a表，否则用不上a表的索引进行排序而是使用排序算法进行排序，使用排序算法效率是很低的。
2. b表驱动a表的时候，增加条件让被驱动表的需要join的记录越少越好，过滤性特别大的一个条件就是add_time字段，过滤的条件越精确性能提示的越多，给add_time字段增加索引后，过滤时间越精确性能倍数的提升（实测）（显示你关注的人最近1小时，最近一天，最近一周，最近一个月等等）。
3. a表加索引idx1(uid,reuid)，可以做到覆盖索引。
4. b表排序可以变相实现，不一定要根据add_time进行排序，比如根据自曾字段进行排序（如果增加了可用的time相关的索引则按time进行排序可能更好）。
5.当系统的数据上升一到两个数量级之后，mysql的join功能几乎不可用，架构上可能就需要改变了。

@xatest 既然你没有特别的需求，那么你应该优化写，而不是想这种怪招，嘿嘿

这样做的目的是什么呢，或者是为了解决什么问题呢？

@Livid 恩，赞成，针对不同的用户给用户提供更多的选择。。

morning