比如我有一张 post,它本应该包含的字段(text 类型的 body 已被移出到附表):
id、user_id、title、description、num_views、num_likes、num_comments、create_time
这时候我要取 posts 列表:
我的问题:
1、上面的读取方式是不是比单纯的 SELECT * FROM post ORDER BY id DESC LIMIT 10000, 20 效率要更高?如果是这样,那随着表记录越来越庞大,是不是把 id 独立出去能够获得更快的 LIMIT 速度?
2、抛开主从/Cache等等其它因素,单纯的读库,因为三个 num_* 字段相对来讲 update 是比较频繁的(特别是 num_views 每次打开文章页都会触发更新),这个 update 和我的 LIMIT 读取是不是在锁机制上存在着排队和竞争?那如果这样,我把这个三个字段独立出去是不是能够增加并发程度(LIMIT 不受 update 的困扰,毕竟 title 和 description 的更新几率要小的多)?
1、覆盖索引查询的确会比普通的limit start,N 方式要好一些。具体的可以实测下,根据我的经验可以增加不少
2、大量update的确会对表造成一些影响。不过不建议大量拆表,这样虽然可以降低写的压力。但是代码结构可能维护起来就很灾难了。毕竟不可能无限进行分表。。建议前面加一层cache。redis or memcache。 数据id_key 进行incr操作,达到某个值进行同步到数据库。比如rand(5,10)。这样数据库压力可以降低很多,效率也可以进行保证。代码维护也没有很复杂。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。