长sql语句和多次sql查询结果进⾏整合，哪种效果⽐较好
sql语句实现的四种功能问题
最近为了实现⼀个功能，仅仅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写的太长的话，后期如果需要维护或者业务有新的需求会⽐较⿇烦
（长远思考：⽅便维护，和添加新的功能），建议是单⼀化，便于维护，便于以后别⼈理解
业务（容易阅读）。业务实现最好是简单明了化，这样出错的⼏率⼩（正确率提⾼）。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。