长sql语句 和 多次sql查询结果进行整合，哪种效果比较好

2019独角兽企业重金招聘Python工程师标准>>>

• 问题

最近为了实现一个功能，仅仅sql语句写了一百多行，最后功能实现了，但是总感觉有一点点愚蠢。因为在每次添加或编辑一个小的功能时，自己很容易就被复杂sql语句给看蒙了，实在太长了，一个括号又一个括号。

这时候我就在想，可不可以将查询结果分多次查询，再将查询结果进行整合，最后返回相同的结果。

1. 首先我们应考虑的时我们所做的业务是否对数据的一致性要求很高，对于财务、网上商城的库存之类的问题，这种情况就需要一条sql搞定；如果分多次查询，当第一次sql执行完毕后，第二次查询的数据又变了，这种情况是不适合拆分sql的。
2. 然后就是考虑功能的实现查分成多条sql是否效率会有提高

无非就是一个sql语句减少了java代码操作的时间，直接返回了需要的数据

多个sql会增加java的代码量，降低java的执行效率（目前我的理解是java效率会比较高，比sql效率相比微乎其微）（好维护，查询效率高）

• 网上答案及个人理解

1：一个一个查出来整合会效率更高
2：分次查询，有利于数据库自动使用到索引，会提高查询效率（极大减少查询时间）
3：一般单表查询，对于业务系统和 orm 框架来说，很多是有缓存的，其实查的是缓存，效率更高，而多表联合查询，一般会禁用这个级别的缓存（利用缓存，减少查询时间）
4：联合查询的sql语句，大多数在查询语法过程中，总数据处理量会变成多表的乘积。总处理数据量是 n*m*...，那么根本就快不起来。而单表查几条，参与运算的数据量就是主数据加几条关联数据。（多表查询复杂度指数型增长）

 

大sql其实比小sql实现起来要麻烦得多，中间夹了太多业务，不仅麻烦也易出错，维护的人也不方便（本人在写这个复杂sql的时候经常想半天，更何况别人要看这个sql的人，应该更是一脸懵逼吧）。相对来说小sql，用自己熟悉的语言如java去实现业务逻辑，比较清晰明了。而且使用小sql查询，也许在缓存中就有都不用去查询数据库。

我本来想的是分成多个sql查询，后来想多次查询数据库会降低效率，所以选择了较长的sql实现功能，后来网友告诉我：

1.有连接池复用，不会有太多明显的多次连接开销；
2.背慢锅的一般都是JOIN；
3.其实在ORM框架来看，JOIN产生了中间结果，不是A也不是B而是AB混合体，因此缓存怎么搞（不用缓存了）所以问题3还是各查个的吧然后在应用里面进行数据处理。
4.有缓存就是吊，不服数据库你自己坐啊 

一次查询：缺点是如果两个表数据多，则中间结果集太大，需要较多的内存资源，以时间换空间。

多次查询的优缺点和一次查询正好反过来。

多次查询也可以在程序中对每一次查询的中间结果做处理，这是一个灵活性。

一次查询如果数据量大的话，多次查询要快一些，相当于是用空间换时间。

• 总结：

分开写多次拼装较好，sql写的太长的话，后期如果需要维护或者业务有新的需求会比较麻烦（长远思考：方便维护，和添加新的功能），建议是单一化，便于维护，便于以后别人理解业务（容易阅读）。业务实现最好是简单明了化，这样出错的几率小（正确率提高）。

转载于:https://my.oschina.net/u/3908739/blog/1922385