sql 联合查询的 优劣比较
2010-01-10 00:49
302 查看
昨天晚上和网友讨论了一个关于数据库联合查询的效率的问题.说实话,以前我一直没怎么考虑过这个问题,在写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,这种比例实在太恐怖了,我不得不对联合查询产生了动摇,难道我们为联合查询的便利,就付出如此巨大的浪费吗?我们真的应该重新审
视一下,我们平时已经习惯的编程习惯,以及那些我们认为理所当然的代码.
当然,以上的计算,有着很多的假定在里面,实际的结果,在不同的数据量,不同的数据库,不同的数据面前,都会有很大的差异,但是,不可否认联合查询的效率,确实不容乐观,如果有需要优化数据查询,特别是大数据量的情况下,很值得思考.
以上只是我的思考,并不代表事实就如此,也许,我一开始的思维方式就错了,如果你有想法,请给我评论时提出,有时间我们一起去验证一下.
转载自:巴士飞扬-技术BLOG
: http://www.busfly.cn/
习惯,或者已经懒散贯了,但是,网友和我聊起来了,我也就好好考虑起这个问题了,平时不考虑时不知道,真正好好计较一下,才发现还有很多门道.
假
设我们有三个表,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,这种比例实在太恐怖了,我不得不对联合查询产生了动摇,难道我们为联合查询的便利,就付出如此巨大的浪费吗?我们真的应该重新审
视一下,我们平时已经习惯的编程习惯,以及那些我们认为理所当然的代码.
当然,以上的计算,有着很多的假定在里面,实际的结果,在不同的数据量,不同的数据库,不同的数据面前,都会有很大的差异,但是,不可否认联合查询的效率,确实不容乐观,如果有需要优化数据查询,特别是大数据量的情况下,很值得思考.
以上只是我的思考,并不代表事实就如此,也许,我一开始的思维方式就错了,如果你有想法,请给我评论时提出,有时间我们一起去验证一下.
转载自:巴士飞扬-技术BLOG
: http://www.busfly.cn/
相关文章推荐
- 公司内部SQL联合查询
- SQL中的联合查询
- SQL查询性能分析之(not in)、(and not)、()、(!=)性能比较
- sql2005 内连接 外连接 交叉连接 查询 与联合查询(合并查询)
- SQL 联合查询
- Sql : 多表联合查询分页
- sql 联合查询子表时间最新的数据
- oracle联合查询并更新一个表字段的sql语句
- sql查询语句中 in和 exists的区别与性能比较
- 2015.7.30 第十五课 sql(新建数据库、创建表、注释、查询语句、新增、更新、删除、联合查询)
- 查询oracle比较慢的session和sql
- sql笔记(联合,连接查询)
- sql 联合查询并更新
- sql 联合查询速度慢,需要对其进行分组
- SQL比较时间查询语句
- SQL联合查询
- 又一个通用分页存储过程,支持表别名,多表联合查询SQL语句
- SQL 函数的应用及比较对于海量数据查询优化
- Sql中联合查询中的”子查询返回的值不止一个“的问题
- SQL查询 [SCOPE_IDENTITY、IDENT_CURRENT 和 @@IDENTITY的区别(比较)]