恭喜 恭喜

得到结果, 再查一次, 把 000000 去掉

@Los 估计抓 10000 w 数据就差不多了,,, 现在上面还放着好多我下的 片片... :)

Update ...

根据@Platinum的建议,加了3个index... , 现在 最长的查询大概3s, 性能10x...,
想办法用cursor中...

def self.up
change_table :posts do |t|
add_index "posts", ["id", "topic_id"]
add_index "posts", ["id", "author_id"]
add_index "posts", ["id", "topic_id", "author_id"]
end
end

@Livid 有一个 post_contents 表 ,

posts 表 有 "post_content_id" 作为关联 , 呵呵 , 只在这个表上有 select * from post_contents where id = xxx 的操作, 这个到成为不了瓶颈.

我的上一次优化就是 把 posts 表 拆成了 posts 和 post_contents 2个表 , 不然 50 W 条数据 就已经跑不动了 :)

douban....

@Platinum 的这个符合索引应该是最简单的, 所有查询排序都能在这个索引中完成, 加了这个索引应该可以提高不少速度
cursor 的 方式 也可以考虑, 但是需要加额外的字段(索引) , 等直接加完索引在看吧


@leolmncn 的这个方式很不错, 等 cursor 改造完, 试试 逻辑分表....


谢谢 :)

create_table "posts", :force => true do |t|
t.integer "topic_id", :null => false
t.integer "author_id", :null => false
t.integer "page_id", :null => false
t.datetime "posted_at", :null => false
t.datetime "updated_at"
t.integer "post_favorites_count", :limit => 2, :default => 0, :null => false
t.boolean "valuable", :default => false, :null => false
t.integer "post_content_id"
end

add_index "posts", ["author_id"], :name => "index_posts_on_author_id"
add_index "posts", ["post_favorites_count"], :name => "index_posts_on_post_favorites_count"
add_index "posts", ["posted_at"], :name => "index_posts_on_posted_at"
add_index "posts", ["topic_id", "author_id"], :name => "index_posts_on_topic_id_and_author_id"
add_index "posts", ["topic_id"], :name => "index_posts_on_topic_id"
add_index "posts", ["updated_at"], :name => "index_posts_on_updated_at"
add_index "posts", ["valuable"], :name => "index_posts_on_valuable"


posts 表 的结构

上面的url 给错了, 应该是这样的url:
http://tianya.lu/topics/10000/pages/23492 才会更慢....

补充一个有这种问题的url

http://tianya.lu/posts/pages/123406

也许会很快, 那是因为有缓存缓存这个页面的时间是10 min, 但是10分钟过期后,,, 用户体验为零. 点了就没反应, 半分钟之后才能动......

卓越. 很久不去当当了, 在 卓越之前是 china-pub

谢谢 楼上的 同学, 我一会去问问, 昨天问了下捌号主机的VPS, 他们给的测试地址结果教育网无法访问 .... 哎, 估计教育网注定是悲剧 :(

都呼呼了吧 ?

肯德基 24 小时外卖热线.... 好饿啊...