(单表查询+代码层组装) or 联表查询问题

从速度上看,网络<磁盘<内存<CPU ,多次sql查询,网络开销是很大的。

要考虑单表查询,首先 service 服务器 和 db服务器网络延迟不能太大。

在实际开发中,我们不可避免的要关联几张数据表来合成最终的展示数据,如:

select * from tag
join tag_post on tag_post.tag_id=tag.id
join post on tag_post.post_id=post.id
where tag.tag='mysql';

同样的,我们可以用以下查询来代替:

select * from tag where tag='mysql';

select * from tag_post where tag_id=1234;

select * from post where id in(123,456,567,9989,8909);

看似后者查询步骤更多了,原本一个方法查询就能出结果,现在直接变成三个。但是这样做的好处是:

  • 更方便阅读,不会一次有很长的sql,每个小步骤划分逻辑也更清晰
  • 代码可复用,join联表的SQL,基本不太可能被复用,但是拆分后的单表查询,如果功能相同则可以复用
  • 提高数据库效率,如果一次连表查询太大,数据库崩溃不说,多表会导致同时锁住多张表,这样性能低。
  • 缓存利用率更高,单次查询,如果数据不经常变化,则可以缓存下来,连表则几乎不行

有的情况下,不适合多次查询,比如:

  • 分开查询的数据庞大,有的时候必须依赖于数据库的连表筛选条件,以过滤更少的数据
  • 分页问题,如果多次查询的结构不合理,则导致分页错乱。
  • 网络问题,如果分开查询每次网络延迟太大,则导致更加缓慢

综上,对系统质量要求较高,比如考虑到以后的分库分表、代码重用、结果缓存等,那么:优先考虑分开查询,如果某个具体问题确实不适合多次查询,则考虑 join。

分开查询,是重业务、轻db的思想,能降低数据库耦合。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注