复杂查询，一条sql多表联合查询 还是 多条sql,循环使用

[贺家小白]

应用中有些复杂逻辑，需要多个条件查询数据。这些条件分布在2~4张表中，那么一般两种方式：
1. 写一条复杂sql,多表关联查询。在服务层代码中只需要使用这条sql。
2. 写多条简单sql,一般是单表查询。在服务层代码中写循环，通过多次使用获取数据。
那么哪种效率更高，我们应该优先是用什么方式？他们的使用场景分别是什么？

[唐_方]

declare @d datetime set @d=getdate() /*你的SQL脚本开始*/ /*你的SQL脚本结束*/ select [语句执行花费时间(毫秒)]=datediff(ms,@d,getdate()) 这个你可以测试一下 一般是多表关联查询快一点，单表还加上了循环，慢一点 优先使用多表查询 单条sql的话 是要查的数据很少的时候使用，设计到多的数据量尽量用多表查询

[nayi_224]

多表关联更好。 更关键的是，2很容易产生那种最垃圾的代码，想让人砸电脑的那种。。。 2没有使用场景

[天涯若风]

个人倾向于，代码层面做查询的控制，要不我们干嘛要有mvc的思想，所有代码都写在web层就好了。 效率方面可能是关联查询要快一点，毕竟每次查询都需要去开个线程，线程链接什么之类的都会耗时。

[ITjavaman]

在不卡表的情况下，推荐多表关联，毕竟还得考虑到数据库连接数

[maradona1984]

复杂查询是只查询一次,网络IO开销较少,这点是优点,但复杂sql随着时间推移,将会越来越复杂,如果计算量大,则会极度耗费数据库服务器资源,而且不易优化,如果存在分表分库的需求,或者服务拆分,复杂sql就是拦路虎
拆分成简单sql,会产生更多次IO操作,这点存在更多耗时操作,所以循环查询这个是不推荐的,但可以通过in来一次查询多条记录,但这种代码就更复杂,好处是容易做到水平扩展,应用服务器做集群远比数据库更简单轻松

如果本身就是多服务架构,还是用简单sql更好,如果是单体架构,复杂sql和简单sql组合都无所谓,但简单sql的组合代码更容易复用,也更能充分利用代码生成工具来生成增删改查代码

一家之言,我是不建议在sql里包含过多逻辑,数据库层就做增删改查,能单表操作就单表操作,你会省去很多时间(sql优化,由于复杂sql导致的bug),也会省去很多成本(DBA可比CRUD程序员贵多了)

[maradona1984]

引用 3 楼 nayi_224 的回复:

多表关联更好。
更关键的是，2很容易产生那种最垃圾的代码，想让人砸电脑的那种。。。

2没有使用场景

我们项目组就是使用2的开发方式,极大的解放了生产力,当然我们的数据库本就是按模块拆分的,业务不紧密的表想关联也关联不起来

为啥用2的方式,多年实践以来,发现系统的瓶颈基本都在数据库,复杂sql就是根源,难优化,也难拆分,业务逻辑分散到sql中,不容易利用IDE等工具定位问题(比如列的别名,case when ,nvl,decode等等,各种能做很多事情的函数),说实话,复杂sql才是真的垃圾代码...让人看不懂,也不利于后期服务的拆分

[nayi_224]

引用 7 楼 maradona1984 的回复:

[quote=引用 3 楼 nayi_224 的回复:] 多表关联更好。 更关键的是，2很容易产生那种最垃圾的代码，想让人砸电脑的那种。。。 2没有使用场景

我们项目组就是使用2的开发方式,极大的解放了生产力,当然我们的数据库本就是按模块拆分的,业务不紧密的表想关联也关联不起来 为啥用2的方式,多年实践以来,发现系统的瓶颈基本都在数据库,复杂sql就是根源,难优化,也难拆分,业务逻辑分散到sql中,不容易利用IDE等工具定位问题(比如列的别名,case when ,nvl,decode等等,各种能做很多事情的函数),说实话,复杂sql才是真的垃圾代码...让人看不懂,也不利于后期服务的拆分 [/quote] 具体是用java还是sql还是要看情况分析的，我这边很多东西就和你的完全相反。比如，我这边java服务器配置一般中高，oracle服务器却几乎是顶配的；核心业务无法做到分库，在其他库的数据也大多会同步到主库，最少也会有个dblink；了解sql的人比了解java的人多；我自己写的复杂sql没人能看懂，最后只能自己维护这种郁闷事也发生过，不过每次维护，用时不会超过5分钟；至于效率方面，用java要跑1小时，用sql一分钟这种事也发生过。不过，楼主也没说这些具体情况，没法讨论了。 按照我对楼主语言的理解，他要做的应该就是4个表通过7、8个条件连接起来。这完全不叫复杂啊，就是最基本的多表查询啊。如果说单表查询相当于 int i = 0; 那多表查询也不过就是 int i, j = 0; 这种语句还能有多复杂？它还能上天了？ 也可能楼主确实遇到了麻烦的问题，但是，既然他什么都没说，咱也不好多想。

[maradona1984]

引用 8 楼 nayi_224 的回复:

[quote=引用 7 楼 maradona1984 的回复:]
[quote=引用 3 楼 nayi_224 的回复:]
多表关联更好。
更关键的是，2很容易产生那种最垃圾的代码，想让人砸电脑的那种。。。

2没有使用场景

我们项目组就是使用2的开发方式,极大的解放了生产力,当然我们的数据库本就是按模块拆分的,业务不紧密的表想关联也关联不起来

为啥用2的方式,多年实践以来,发现系统的瓶颈基本都在数据库,复杂sql就是根源,难优化,也难拆分,业务逻辑分散到sql中,不容易利用IDE等工具定位问题(比如列的别名,case when ,nvl,decode等等,各种能做很多事情的函数),说实话,复杂sql才是真的垃圾代码...让人看不懂,也不利于后期服务的拆分
[/quote]

具体是用java还是sql还是要看情况分析的，我这边很多东西就和你的完全相反。比如，我这边java服务器配置一般中高，oracle服务器却几乎是顶配的；核心业务无法做到分库，在其他库的数据也大多会同步到主库，最少也会有个dblink；了解sql的人比了解java的人多；我自己写的复杂sql没人能看懂，最后只能自己维护这种郁闷事也发生过，不过每次维护，用时不会超过5分钟；至于效率方面，用java要跑1小时，用sql一分钟这种事也发生过。不过，楼主也没说这些具体情况，没法讨论了。

按照我对楼主语言的理解，他要做的应该就是4个表通过7、8个条件连接起来。这完全不叫复杂啊，就是最基本的多表查询啊。如果说单表查询相当于 int i = 0; 那多表查询也不过就是 int i, j = 0; 这种语句还能有多复杂？它还能上天了？

也可能楼主确实遇到了麻烦的问题，但是，既然他什么都没说，咱也不好多想。[/quote]

那确实需要具体场景具体分析,我说的这种只是在踩了很多坑之后新的尝试,效果还行,因为sql这东西换个人来看就还真不太容易理解其意图了,这涉及到数据模型+业务逻辑,对这两者都要了解才能真正理解表关联之后的数据结构,我这种做法的目的是减少对人的依赖罢了

[bcsflilong]

复杂查询比较好 循环的调用dao 这样性能不是很好 尽量较少数据库的访问 一次能拿出来的 不要拿多次

[RUA好多鱼~]

多表连接不是会比较慢么？

[人海中浮沉]

引用 6 楼 <span style="color:#4788C7">maradona1984</span>的回复:

复杂查询是只查询一次,网络IO开销较少,这点是优点,但复杂sql随着时间推移,将会越来越复杂,如果计算量大,则会极度耗费数据库服务器资源,而且不易优化,如果存在分表分库的需求,或者服务拆分,复杂sql就是拦路虎
拆分成简单sql,会产生更多次IO操作,这点存在更多耗时操作,所以循环查询这个是不推荐的,但可以通过in来一次查询多条记录,但这种代码就更复杂,好处是容易做到水平扩展,应用服务器做集群远比数据库更简单轻松

如果本身就是多服务架构,还是用简单sql更好,如果是单体架构,复杂sql和简单sql组合都无所谓,但简单sql的组合代码更容易复用,也更能充分利用代码生成工具来生成增删改查代码

一家之言,我是不建议在sql里包含过多逻辑,数据库层就做增删改查,能单表操作就单表操作,你会省去很多时间(sql优化,由于复杂sql导致的bug),也会省去很多成本(DBA可比CRUD程序员贵多了)

<br />我就遇到过，复杂sql查询的业务，大概就是统计一个概率，先统计分子，再统计分母，最后相除得出概率，还要排序，像这种一条sql是很复杂的，而且数据量一大，非常的慢，但在代码里拆开来分两个方法去访问数据库，也不行，因为方法调用不是异步的，速度一样慢，除了异步执行dao方法访问数据库，真不知道还能怎么优化了