在昨天的文章《为什么强烈建议你不要做联表查询？》中，大家提了一些比较有意义的问题，留言回复说不太清楚，今天单开这一篇做一些说明。
首先，在实际开发中，还是应该多使用单表查询，这样无论在性能上或者后续维护上，都会比复杂的关联查询要好，很多高性能的应用都会对关联查询进行分解。但是针对一些不同的场景，也应该比较灵活的采取join查询的方法，原则上join不要超过三张表。
数据库连接次数过多，效率更低
单表查询势必要考虑2次连接带来的开销，但是，MySQL对连接/断开是有处理的，而且网络越来越快，相比单表查询能够让缓存效率更高的这个优势下，多两次的连接所带来的开销基本可以忽略不计。（指一般业务下，具体问题还要具体分析）
多条件过滤+分页难实现
这里贴一个代码片段
无论是哪个表需要传参查询，最终都有一个符合条件的结果集，最终我们组合查询后的结果集，多条件过滤无法实现的问题就不存在了。至于分页，使用 com.baomidou.mybatisplus.core.metadata包下的IPage，很强大，谁用谁知道！
附代码：
public PageResult<ApplyVO> searchApplyPage(Page<Apply> page, Integer approvalStatus, String proposerCard, String message){ List<Long> ids = Optional.ofNullable(this.applyMapper.findMedicineApplyIds()).orElse(new ArrayList<>()).stream().map(Apply::getId).collect(Collectors.toList()); List<ApplyVO> applyVOS = Lists.newArrayList(); if(CollectionUtils.isEmpty(ids)){ return PageResult.of(applyVOS,0); } Page<Apply> apps = this.applyMapper.selectPage(page, new QueryWrapper<Apply>().lambda() .in(Apply::getId,ids) .eq(!Objects.isNull(approvalStatus), Apply::getApprovalStatus, approvalStatus) .eq(!StringUtils.isEmpty(proposerCard), Apply::getProposerCard, proposerCard) .and(!StringUtils.isEmpty(message), i-> i.like(Apply::getTeamName, message).or() .like( Apply::getProposer, message).or() .like(Apply::getAthleteName, message)).orderByDesc(Apply::getApprovalNumber) ); apps.getRecords().forEach(s->{ List<MedicineDetail> medicineDetails = this.detailMapper.selectList(new QueryWrapper<MedicineDetail>().eq("apply_id", s.getId())); MedicineApplyVO medicineApplyVO = MedicineApplyVO.builder().accompany(s.getAccompany()).medicineDetails(medicineDetails).build(); applyVOS.add(medicineApplyVO); }); return PageResult.of(applyVOS,apps.getPages(),apps.getCurrent(),apps.getCurrent(), apps.getTotal()); }
排序分页不同表的问题
这种，不考虑，直接join查询，数据组装或许能实现，但是没必要搞这么复杂，推荐大家使用分表查询，但不是所有的都必须分表，一看就是联表更方便的，我们一般都直接联表写SQL。
基本都解答完了，对于一头磕在键盘上的同学的留言，说的完全有道理，虚心接受，上一篇文章其实主要是推荐大家在开发中尽量使用单表查询，单表查询优点>缺点，既然是鼓动大家使用单表查询，我必然是介绍它的优点，哈哈。
但是在实际开发中，一些场景明显使用联表查询更方便，我也会去使用联表的方式，比如多喝热水同学的留言问题，不用考虑，直接联表查。
