慢sql和多次sql查询那个好?

踏破铁鞋无觅处 发布于 2018/08/02 09:13
阅读 6K+
收藏 6

今天为了实现一个功能,光sql语句写了五六十行,每次修改sql的时候,也会想半天,感觉sql写的很复杂

那么对于复杂的功能,多次查询后整合好,还是一个sql查询出来好呢?

 

查询结果是多条数据

加载中
5
sxgkwei
sxgkwei

飘摇清风 说的业务场景非常有道理,所以你得先考虑业务场景是否有强一致性要求。其次,大多数情况下,我觉得一个一个查出来整合会效率更高。原因如下:

1,你能问这个问题,一般认为就是页面展示查询。那么为了完成整体目标而分次查询,总次数也不会太多。

2,分次查询,有利于数据库自动使用到索引,会提高查询效率

3,一般单表查询,对于业务系统和 orm 框架来说,很多是有缓存的,其实查的是缓存,效率更高,而多表联合查询,一般会禁用这个级别的缓存(因为缓存了可能因为其它位置修改其中一个表的数据而导致缓存更新不了,导致查询出错误数据),就会导致联合查询更慢。

4,联合查询的sql语句,大多数在查询语法过程中,总数据处理量会变成多表的乘积。总处理数据量是 n*m*...,那么根本就快不起来。而单表查几条,参与运算的数据量就是主数据加几条关联数据。

 

综上,在大多数情况下,实际上关联的复杂 sql 查询,在整体应用层面,会是个差劲的选择。

H
Hogwarts1024
回复 @sxgkwei : 好的,谢谢回答
sxgkwei
sxgkwei
回复 @小船大帆 : 比如物品管理,物品可以被借出这种场景。那么就应该在设计时就在物品表上有是否被借出的字段来标记。而不是每次有人发起想借申请时,跑去借出记录表去check这个物品目前在不在库房。查询出借记录肯定会是个大表,而且记录还有个归还时间,会让check非常耗时。
sxgkwei
sxgkwei
回复 @小船大帆 : 是的,只能联表查询。不过这个是个设计问题,设计者在设计初期从表设计上就应该尽量避免这种情况。如果数据量较大时,设计时就应该考虑可能会被用于业务的查询字段,做字段冗余设计。
H
Hogwarts1024
借楼问个问题,联表查询效率比较低,但是如果涉及到分页的话该怎么办,涉及的条件字段在不同的表,这种情况下只能联表了吗
sxgkwei
sxgkwei
回复 @飘摇清风 : 对的,容易理解易维护才是首要问题
下一页
3
飘摇清风

似乎不同的行业不同的应用要求不一样吧?我做的应用是超大数据量,但一插入变化就不大的,一般是拆成多条sql查询出来拼装。因为数据变化不大,数据一致性问题比较小,也不会因为数据量太大而长时间锁表。如果你的应用对数据一致性要求很高如财务、网上商城的库存之类的,感觉还是一条sql搞定好点,不然查询了一部分后,前面查询的数据又变了,数据就不太一致了。

PS:我因为一条大sql查询把服务搞死过。。。

踏破铁鞋无觅处
踏破铁鞋无觅处
我忘了说,我的查询结果是多条数据,如果拆分多条sql,需要多次拼装,这样还需要关键字进行遍历,整合。 会不会比较麻烦了。 不如多次使用left join进行查询啊
2
JavaGG
JavaGG

我自己一般是先考虑多sql查找,因为方便做cache,如果一条就无办法了,一条sql也比较难维护,如果写的人走了,估计接手的要死

1
小小行者
小小行者

大数据、海量数据业务场景下,单表多次查询是最优方案

1
aplat
aplat

建议从3个方面考虑:

1.了解系统的职责边界,非本系统的业务可以使用大sql,这样便于维护

2.本系统业务要考虑相关子业务如果毁灭,其他业务线不应该受到直接影响,影响系统的健壮性

3.从系统和业务层看待问题,性能低,有N种优化的方式。本质还是看对系统的理解,和服务边界的理解

 

1
zhjh256
zhjh256

这个讨论的就是废话,前提是你要什么,效率?可维护性?就像说你要去北京,你要什么时候到、花费多少都没说就讨论怎么去,有意义????

0
melon_jj
melon_jj

如果数据量小的话基本没有区别。

一次查询的优点是只需要一次连接,数据库查询的时候,连接是个耗时的操作。缺点是如果两个表数据多,则中间结果集太大,需要较多的内存资源。

多次查询的优缺点和一次查询正好反过来。另外多次查询也可以在程序中对每一次查询的中间结果做处理,这是一个灵活性。如果数据量大的话,多次查询要快一些,相当于是用空间换时间,如你上述所说,拼装sql会比较麻烦,但带来的是效率的提升,我认为还是值得的。如果表中建立了大量的索引的话,索引的命中率也很高。效率也会大幅提升。

melon_jj
melon_jj
这样吧,你加一下我QQ,我语音给你说一下好了·· 3474203856
蓝水晶飞机
蓝水晶飞机
补充一下:1、其实平常有连接池复用,不会有太多明显的多次连接开销;2、在我做的系统里面,背慢锅的都是JOIN;3、其实在ORM框架来看,JOIN产生了中间结果,竟不是A也不是B而是AB混合体,因此缓存怎么搞(不用缓存了)所以问题3还是各查个的吧然后在应用里面进行数据处理。4、有缓存就是吊,不服数据库你自己坐啊。
0
魔力猫
魔力猫

不提具体业务需求、数据结构的情况下,讨论这个没有意义。

 

0
IdleMan
IdleMan

引用来自“魔力猫”的评论

不提具体业务需求、数据结构的情况下,讨论这个没有意义。

 

数据库count好还是select清单到程序中计数好?

数据库中跑神经网络如何?

0
Choco_men
Choco_men

个人建议是分开多次拼装好点,sql写的太长的话,后期如果需要维护或者业务有新的需求会比较麻烦,建议是单一化,便于维护,便于以后别人理解业务。

返回顶部
顶部