« Velocity与Struts2标签相结合使用,功能值得期待« »又一次成功解决Mysql乱码问题 »
数据库SQL联合查询的思考

昨天晚上和网友讨论了一个关于数据库联合查询的效率的问题.说实话,以前我一直没怎么考虑过这个问题,在写SQL时,都没怎么考虑,似乎一切都成了习惯,或者已经懒散贯了,但是,网友和我聊起来了,我也就好好考虑起这个问题了,平时不考虑时不知道,真正好好计较一下,才发现还有很多门道.

假设我们有三个表,A表,B表,C表.其数据量分别为100,200,300条记录.并且假设每次都是完全遍历所有数据才找到结果(其实一般情况下不会真的需要完全遍历完才能找到结果),并且假设不考虑索引,当然,就算不排除这些因素,结果比例还是一样的,只是数据大小上有点不一样.并且假设每次查询都查出10个结果.


一般我们的查询语句是这样的:

select * from a,b,c where a.id=b.aid and b.id=c.bid

 

那这些的查询效率大概是怎样的呢?它相当于先将这三表进行组合,再遍历查询,查询量为100*200*300=600万.好像很吓人,这只是1,2,3百的三个表,如果个1,2,3百万,千万呢,那是不是很恐怖呢?


那我们应该如何进行优化呢?依我的理解,可以不使用三表联合查询,分成多个查询,过滤大量的数据再进行联合,这样的话,再联合时,就可以大量减少遍历次数,比如以下方式:

方式1: 将三表联合分成两个2表联合查询,如:先进行AB联合查询,再将结果与C联合. 这样查询遍历次数为:100*200+10*300 =2.3万.

类似的SQL为: select * from (select * from a , b where a.id = b.aid) as ab, c where ab.id=c.bid

方式2:先对各表进行过滤,再进行三表联合,或者2表联合: 这样查询的遍历次数为:100+200+300+10*10*10=1600.,或者:100+200+300+10*10+10*10=800.

类似的SQL为: select * from (select * from a where ...)as a,(select * from b where ....) as b, (select * from c where ....) as c where a.id=b.aid and b.id=c.bid

或者: select * from (select * from (select * from a where ...)as a ,(select * from b where ....) as b where a.id = b.aid) as ab, (select * from c where ....) as c  where ab.id=c.bid


根据以上的思考,结果很吓人,经过对比,发现,结果好恐怖,遍历次数差别简直就是.........比比看看:600万--2.3万--1600--800,这种比例实在太恐怖了,我不得不对联合查询产生了动摇,难道我们为联合查询的便利,就付出如此巨大的浪费吗?我们真的应该重新审视一下,我们平时已经习惯的编程习惯,以及那些我们认为理所当然的代码.

当然,以上的计算,有着很多的假定在里面,实际的结果,在不同的数据量,不同的数据库,不同的数据面前,都会有很大的差异,但是,不可否认联合查询的效率,确实不容乐观,如果有需要优化数据查询,特别是大数据量的情况下,很值得思考.

以上只是我的思考,并不代表事实就如此,也许,我一开始的思维方式就错了,如果你有想法,请给我评论时提出,有时间我们一起去验证一下.

 


Tags: SQL  数据库  oracle数据库  MYSQL数据库   |

原创文章如转载,请注明:转载自:巴士飞扬-技术BLOG : http://www.busfly.net/

本文链接地址:http://www.busfly.net/post/unit-sql-table.html

如果你喜欢本文,请顶一下,支持我,你的支持是我继续发好文章的最大动力。谢谢。
好东西需要分享,快把本文发给你的朋友吧~!~

     
相关文章:
  • 引用此留言  11.sean  
  • 联合查询是采用的笛卡尔集的方式,where语句中是筛选条件,数据量肯定是大的。为什么提出的解决方法没有用join方式呢? 难道 inner/outer join也用的笛卡尔集?
  • [删除]2009-4-30 12:39:51 回复该留言
  • 引用此留言  10.utopian  http://www.bootad.cn
  • 从我做数据的经验来看,首先要弄清楚表与表之间的逻辑,来决定是做内连接还是外连接,哪个是主表,哪个是从表;第二步是优化数据库,尽可能使用合理的index;第三步,才是写出高效的SQL。
    百万级的查询,不算大,只要合理使用,速度还是很快的,最重要的是看逻辑。
  • [删除]2009-4-26 23:01:50 回复该留言
  • 引用此留言  2.阿傻  
  • 肯定要联合查询啦,无论在什么情况下,特别是数据库不是你一个人在用的时候!
  • [删除]2009-4-2 15:15:12 回复该留言




◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。
网站分类
分类最近文章
最近发表
最新评论及回复
最近留言
热文排行
随机推荐文章
Powered By Z-Blog   STYLE by busfly . FatMouse
Copyright © 2007 巴士飞扬技术博客. . 沪ICP备07027972号. 会员群1(J2EE为主):3769186.