优先使用单表查询，而非联合查询

发表于2016/7/4 17:49:09 1866人阅读

分类：研发架构

一、小雷的见解
1.编码规范

CRUD，命名规范，可以通用。
比如类名、方法名、变量名，都很接近。

2.开发效率

复制粘贴很方便。

自动化生成很爽。

标准API容易定义。
针对单表的链式操作框架，也很多。

3.代码简单易懂

一个表，再复杂的sql，很快也能看懂。

一般的sql，刚刚毕业的大学生，也看得懂，写得出来。
<select id="get" resultType="cn.fansunion.shopping.Order">

select <include refid="columns" />

from order_order

where id =

#{id}

</select>

4.分库分表

数据量大了之后，分库分表，sql基本不受影响。

话说当当开源的sharding-jdbc，不支持联合查询吧。

https://github.com/dangdangdotcom/sharding-jdbc

5.可扩展强

持久层API，职责单一，很容易重新组合。

6.缓存

单表查询的数据比较明确，缓冲命中率高。

如果是多表查询，其中1个表变了，另外1个表没变，还需要重新查询。

二、海尔电商总监-Richie

简单说说

1. 从逻辑架构分层原则来看

关联关系代表了业务规则/逻辑，毫无约束大量使用关联查询，就是把大量的业务规则和逻辑放在数据库来执行了，数据库消耗cpu、内存、io等资源进行关联操作，实际上是在做应用该做的事情。

2. 从资源利用率方面看

大部分场景下，并不是所有关联查询的结果都被有效使用了。例如后台管理的列表界面，通常都会分页显示，关联查询的结果集，只有当前页的数据被使用，其他都是无用的，但数据库需要消耗额外资源得到全部结果集，再从中得到当前页数据。

3. 从架构的伸缩性方面看

大量的关联查询会导致集中式的数据库架构很难向分布式架构转换，伸缩性方面的优化难度高。

关联查询方便快速，开发效率比较好，如果系统、数据库经过一些垂直优化手段完全能够满足性能要求是可以使用的，例如中小企业的内部管理系统等。

不使用关联查询在架构层面有很多优点，但对系统分析和设计、开发能力要求高。一般在互联网行业等用户数较多的情况下最好重视这方面。

理论上不存在什么复杂场景，如果不使用数据库的关联查询就无法满足需求的。巨无霸的ERP系统SAP，基本整个系统功能都是用单表查询实现的

https://www.zhihu.com/question/21319692/answer/35443564

三、《高性能MySQL》-权威解读

https://www.zhihu.com/question/21657443