我知道有很多关于这个主题的帖子，但我最近一直在倾注于这个话题，并想听听其他一些同样在做同样事情的人的结论。我刚开始使用 Graph API 使用 Graph 获取数据的样式...
$facebook->api('/me/posts');
问题是，它看起来很慢，但它是可靠的。当我将每个查询设置为 100 个帖子的限制时，我收到了这 100 个帖子，甚至获得了一个友好的小分页链接来获取下一组。
但就像我说的，查询速度很慢，所以我尝试了 FQL，它似乎处理事情的速度更快，并且让我对我请求的数据有更强的控制力，并让我在哪些数据方面有一些真正的自由特别想要。但是 FQL 的可靠性很差。我可以制作一个询问 1000 个结果的查询，但只能得到 93 个结果。我读到 facebook 抓取了 1000 个，然后取出了由于各种原因我不应该看到的那些，并给了我剩下的，这使得任何形式的步进都变得困难，结果虽然有点快，但非常不准确。
$query = 'SELECT post_id, actor_id, comment_info, created_time, description_tags, like_info, message, message_tags, place, share_count, source_id, tagged_ids, type, with_location, with_tags FROM stream WHERE (type=46 OR type=56 OR type=80 OR type=128 OR type=247 OR type=285) AND source_id = me() AND (actor_id = me() OR actor_id IN(SELECT uid1 FROM friend WHERE uid2=me()) ) AND created_time > '.strtotime("-1 year") .' LIMIT 50000
那个庞大的查询只给了我 95 个帖子，并设法及时恢复了将近六个月。
我承认我仍然在学习 FQL 的细节，但 SQL 是我精通的东西。
所以我的问题是，我应该坚持 FQL 的乏味并继续微调这些请求，还是应该接受缺乏控制和使用友好 facebook Graph 的速度稍慢的问题？