这个命题难度其实不小，相当于微博（所关注对象的转发信息）的需求了。

我不清楚微博的数据模型是怎么设计的，所以只能提点我自己的想法了：
1、无限时间范围的查询是不合理的，而且支持难度很高；
2、预处理是必需的，否则每次检索和排序的开销比较高，尤其是排序要设法避免，因为如果要进行排序（按时间）就意味着所有数据都必须检索出来后才能开始排序；

大致设计如下：
◎ 设计一张当期浏览日志表，字段：浏览时间、浏览者ID、浏览ID、其它浏览信息；
　　主键：浏览时间、浏览者ID、浏览ID，簇集索引。
◎ 该表信息应该以特定时间周期（比如一个月）来保持一定规模，不能无限制扩大；
　　超过该时间范围的浏览信息，可以移入另一张表：“近期浏览日志表”
◎ 检索时先把朋友Select出来，然后再使用In来进行检索；因为簇集索引第一字段是时间，所以不需要再使用OrderBy关键字；注意限制返回记录数，不要一次性返回所有。


以上是初步想法，如果是类似微博的要求，这个肯定是不够的，还需要更多的空间（内存、磁盘）和预处理来换取时间。

我能想到的预处理有两类：
1、利用内存：将近期的浏览日志按用户Hash放入内存，那么检索时直接可以取出300个用户的近期记录，然后做一次快排。
2、利用磁盘：给每个用户设置一个固定容量的“消息盒子”，每当有某个被关注用户新出现浏览记录（或者说发推），则向所有关注该用户的“消息盒子”以异步准实时的方式投递一条简短信息。

在脑子里判断是方案2速度更高，但是需要评价下磁盘开销。

想办法把这个好友关系的信息，逐步拉到你的服务器这边来咯。
你这边所服务的用户A，必然可以取得他的好友信息B。那么反过来考虑，B如果有记录，不管他的好友是否还有XYZ，你也只需要在A的盒子放一条消息即可，因为反正XYZ不是你系统所服务的用户。
等X某天成为了你系统所服务的用户，那么注册完成后初始化一次盒子信息就是了。