sql server联合查询内使用子查询

本文探讨了在SQL Server中使用联合查询时,直接在JOIN后跟随子查询与先将子查询结果存入临时表两种方式的效率差异。通过实际例子,发现直接使用子查询的效率远低于预期,其执行了多次子查询,而将子查询结果存入临时表再进行联合查询的方式更优。作者计划进一步研究这一现象的原因。

原来一直以为join后面写个查询语句,sql server会自己生成一个worktable,然后再进行联合查询,但是今天的三观被刷新了一次。

book_month_deli是一张统计每月信息的表,book_cost是记录流水账的表。下面sql就简单地写:

语句1

SELECT *

FROM book_month_deli a WITH(NOLOCK)
LEFT JOIN (SELECT 
            t1.shopid AS shopid
            ,SUM(t1.busisum) AS delisum
        FROM book_cost t1 WITH(NOLOCK) 
        WHERE t1.billdate='2016-10-08'
        GROUP BY t1.shopid
) b ON a.shopid = b.shopid
WHERE a.billmonth>='2016-05' AND a.shopid='00000040'

语句2
SELECT *
FROM book_month_deli a WITH(NOLOCK)
LEFT JOIN (SELECT 
            t1.shopid AS shopid
            ,SUM(t1.busisum) AS delisum
        FROM book_cost t1 WITH(NOLOCK) 
        WHERE t1.billdate='2016-10-08'
        GROUP BY t1.shopid
) b ON a.shopid = b.shopid
WHERE  a.shopid='00000040'

 咋一看感觉是语句1的效率高于语句2,其实不然,语句1的耗时居然是2的8倍以上,打开IO统计后执行语句的结果如下:

(8 行受影响)
表 'book_cost_1610'。扫描计数 8,逻辑读取 60272 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'book_month_deli'。扫描计数 1,逻辑读取 2 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。


(51 行受影响)
表 'Worktable'。扫描计数 0,逻辑读取 0 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'book_cost_1610'。扫描计数 1,逻辑读取 7534 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'book_month_deli'。扫描计数 1,逻辑读取 2 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。


很显然语句1执行了8次子查询,而语句2和我原来想的一样先生成了一个中间结果的内部表,可是具体是因为什么问题导致这个情况发生还是一头雾水,过几天空闲了再找资料了,先记录下这个bug,额,还有以后要学乖了,这种情况先把子查询结果放到临时表里,然后将临时表进行联合查询


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值