从速度上看，网络<磁盘<内存<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的思想，能降低数据库耦合。