SQL使用（二）—–联合查询和单查询的优缺点
联合查询可以通过多步单查询来完成，那么什么时候用联合查询，什么时候用单查询呢？它们的优缺点各是什么呢？想必大家跟我一样也存在这种疑惑，我经过搜索相关资料，现对联合查询和单查询进行如下总结：
首先从我个人经历出发谈谈我的感受，在学校的时候虽然也学过联合查询等知识，但是由于自己嫌记得东西太多就没有好好去研究，所以没工作之前一直在用单查询去做。工作之后，单位的项目很多地方用到联合查询，*之下只能去学习，慢慢得也对联合查询有了一定理解。公司处理的数据量相对较大，所以查询的速度也会慢，效率问题成了关键，就搜索了相关资料来研究联合查询和单查询的优缺点。
个人看法：
就我自身而言，我更倾向于用单查询，理由很简单，单查询可重用性高，相对简单容易理解，而且做分库等改动较小。与联合查询相比较，单查询需要自己用代码去完成联合查询的逻辑，相对繁琐工作量较大，联合查询只要开发人员能够充分理解并且熟练使用，开发效率会提高很多，但是大量的联合查询会让系统进行分库时改动较大。-
综合见解：
从开发效率来看：
联合查询是需要多个单查询进行逻辑组合才能完成的查询的工作，联合查询仅仅需要一个SQL就可以完成查询工作，即把业务逻辑放到了SQL中，由数据库来处理，相对来说开发效率会比较高些。从查询效率来看：
查询的执行流程：连接数据库、传入SQL、执行SQL语句、返回查询结果、断开连接；
无论是单查询还是联合查询，进行查询时都是需要进行上述流程的。传统的实现中，认为需要让数据库来完成更多的工作，这样做的原因在于网络通信、查询解析和优化是一件代价很高的事情。然而现在的众多数据库在设计上连接和断开连接都是轻量级的，返回一组小的查询结果也很高效。并且现在的网络速度与之前相比也快了很多，连接数据库、返回查询结果、断开连接的耗时不在是影响效率的主要原因。那么SQL的执行耗时成了关键，多个单查询的耗时根据情况不同无法与联合查询的耗时进行对比，不过我们可以通过以下几个方面进行考虑：
1.缓存效率：
数据库是存在缓存机制的，但一条SQL执行之后，再次执行相同的SQL，数据库会把缓存的结果返回出去，而不会重新查询数据库。单查询的可重用性较高，所以缓存效率相较之联合查询会更高。
2.锁竞争
熟悉多线程的同学相信对锁机制一定不陌生。为了保证数据库的数据同步，在数据库进行读写时，数据库会用锁机制，限制其他连接对其操作。读写越快，数据库的并发性越高。由于联合查询查询速度比单个查询要慢很多，这样联合查询会增加锁的竞争关系，所以用单查询会更好些。
3.查询结果有效使用率
相较于联合查询，单查询的查询结果有效利用率要高很多，也就是说联合查询会浪费一些时间在查询无用的数据上。例如后台管理的列表界面，通常都会分页显示，关联查询的结果集，只有当前页的数据被使用，其他都是无用的，但数据库需要消耗额外资源得到全部结果集，再从中得到当前页数据。从逻辑架构分层原则来看
关联关系代表了业务规则/逻辑，毫无约束大量使用关联查询，就是把大量的业务规则和逻辑放在数据库来执行了，数据库消耗cpu、内存、io等资源进行关联操作，实际上是在做应用该做的事情。从资源利用率方面看
大部分场景下，并不是所有关联查询的结果都被有效使用了。例如后台管理的列表界面，通常都会分页显示，关联查询的结果集，只有当前页的数据被使用，其他都是无用的，但数据库需要消耗额外资源得到全部结果集，再从中得到当前页数据。从架构的伸缩性方面看
大量的关联查询会导致集中式的数据库架构很难向分布式架构转换，伸缩性方面的优化难度高。关联查询方便快速，开发效率比较好，如果系统、数据库经过一些垂直优化手段完全能够满足性能要求是可以使用的，例如中小企业的内部管理系统等。不使用关联查询在架构层面有很多优点，但对系统分析和设计、开发能力要求高。一般在互联网行业等用户数较多的情况下最好重视这方面。理论上不存在什么复杂场景，如果不使用数据库的关联查询就无法满足需求的。巨无霸的ERP系统SAP，基本整个系统功能都是用单表查询实现的。
综上所述：单查询相较于联合查询的更适用于现在的开发理念，个人也很倾向于单查询，虽然麻烦些，但是做为开发人员，单查询可以让开发人员的思路更清晰些。
参考资料：
https://www.zhihu.com/question/21319692/answer/35443564
《高性能Mysql》
如果大家觉得有不对或者有更好的见解，欢迎大家批评指正！