为啥嵌套查询速度更快

nkgsm

根据教科书讲的，好像尽量不要使用嵌套查询，会影响速度，但我对比试验了一下如下两段语句，发现嵌套的比不嵌套的快了10秒，3个表都有4000多行，那位高手能解释，谢谢了
嵌套的语句如下
select a.F1 as 法人码,b.F2 as 单位名,a.F2 as 就业人数,a.F9 as 就业平均人,a.F13 as 工资额,c.就业平均工资,c.在岗人数,c.在岗平均人数,c.在岗工资,c.在岗平均工资 from [数据$]a,[劳资字典库$]b,
(select F1,(F6+F7)as 在岗人数,(F10+F11)as 在岗平均人数,(F14+F19)as 在岗工资,iif(F9>0,round(F13/F9*1000,0))as 就业平均工资,iif(F10>0,round(F14/F10*1000,0))as 在岗平均工资 from [数据$])c
where a.F1 not in (select F1 from [三上字典库$]) and a.F1 = b.F1 and a.F1=c.F1
不嵌套的语句如下
select a.F1 as 法人码,b.F2 as 单位名,a.F2 as 就业人数,a.F9 as 就业平均人,a.F13 as 工资额,iif(a.F9>0,round(a.F13/a.F9*1000,0))as 就业平均工资,(a.F6+a.F7)as 在岗人数,(a.F10+a.F11)as 在岗平均人数,(a.F14+a.F19)as 在岗工资,iif(a.F10>0,round(a.F14/a.F10*1000,0))as 在岗平均工资 from [数据$]a,[劳资字典库$]b
where a.F1 not in (select F1 from [三上字典库$]) and a.F1 = b.F1
三个表关联的目的是，数据表没有劳资字典库表的单位名称，所以必须关联之，又必须不能包含三上字典库表的单位名称，故必须关联之。还有数据表本身还要计算（加和除）
上述嵌套查询运行了1分20秒，不嵌套查询运行了1分30秒

凌空一羽

多表查询？联合查询，不懂不懂，楼主能解释一下吗？{:soso_e163:}

nkgsm

怎么没有人回答，急切盼吴想版主解释。
我个人的理解，这里from后面的那个嵌套查询，是一个计算过程，把它单独做一张表，可能反而节省内存，因为，不单独做，放到一起做，可能就是一个很大的内存活动范围，反而影响速度。
不知道是否胡说八道。

在和弦处等你

猜一个：多表查询的速度快于子查询的{:soso_e113:}

nkgsm

自己专研了一下，发现是那个not in子查询拖慢速度，去掉那个not in，保留其他条件，查询1秒即过。怎么这个not in子查询会拖慢速度呢？不得其解。

amazeyeli

嵌套查询?貌似没有效率一说吧!

只听过子查询和关联查询效率的说法,也许是孤陋寡闻

in,not in 本身就不是什么好东西

还有 distinct ,like '%a' 等等

amazeyeli

where a.F1 not in (select F1 from [三上字典库$])

where not exists
(select 1 from [三上字典库$] where f1=a.f1)

nkgsm

感谢6楼SQL高手的回答
说的in,not in 本身就不是什么好东西
还有 distinct ,like '%a' 等等
只能说在效率上面不是好东西，但还是能解决问题。
确实这个in和not in怎么会拖慢速度，难道它是函数？函数只听说在一般的计算那里，数据多了会影响速度，在SQL查询也会影响速度？

nkgsm

自己分析了原因，not in的比对是笛卡尔积式的比对，比如两个表各4000条，则4000×4000=16000000，1千6百万条数据，是一个庞大的数据量，所以当然耗时。