难道SQL的子查询就是鸡肋吗？
本人的文章发布之后有很多朋友都给出了自己的想法,很多都不错,主要的一种说法就是利用join来替代子查询,可是如果说在取出的字段特别多的时候,进行分组时 group by 中会出现多个字段,这在性能上也未必会好.而且这只是一种解决方案,能不能以我文章中的性能问题分析一下具体原因呢?为什么第二种方案效率会更好呢?
Feedback
#1楼 2008-05-13 11:21 个人知识管理
1.查询表TB_RESOURCE_INFO总共11次,连接数据库11次：肯定是对数据库连接池没有理解，程序出错导致
2.子查询作为字段的值返回还是第一次看到，因为没有条件限制，本例不应用子查询，应直接用Join。必要时应引入“冗余字段”
#2楼 2008-05-13 11:23 PerfectDesign
楼主能不能将这两个语句的执行计划和IO，以及时间方面的统计贴出来，好对比对比，你这样还是没看懂啊
#3楼 2008-05-13 11:26 PerfectDesign
@个人知识管理
子查询是可以用作字段值的，只不过一般这种情况都会优化成连表查询。
不过不明白你说的 对数据库连接池没有理解，程序出错导致 什么意思..
#4楼 [楼主] 2008-05-13 11:29 姜敏
@ 个人知识管理
1.查询表TB_RESOURCE_INFO总共11次,连接数据库11次：肯定是对数据库连接池没有理解，程序出错导致
请教这是什么意思啊？
#5楼 [楼主] 2008-05-13 11:33 姜敏
@ 个人知识管理
2.子查询作为字段的值返回还是第一次看到，因为没有条件限制，本例不应用子查询，应直接用Join
如果是join的话，那么在有统计函数count()的时候，不是还要进行分组吗？
如果查询的字段比较多， 那么group by 的字段就会特别多，这样在性能上也不会太好吧。
#6楼 [楼主] 2008-05-13 11:34 姜敏
@PerfectDesign
楼主能不能将这两个语句的执行计划和IO，以及时间方面的统计贴出来，好对比对比，你这样还是没看懂啊
哈哈，抱歉我用的是interBase数据库，好不能显示执行时间啊。
#7楼 2008-05-13 11:37 PerfectDesign
@姜敏
推荐使用索引视图来做
count函数还是可以应用索引视图的。
建议直接建一个索引视图
#8楼 2008-05-13 11:40 PerfectDesign
居然.
#9楼 [楼主] 2008-05-13 11:44 姜敏
@PerfectDesign
推荐使用索引视图来做
count函数还是可以应用索引视图的。
建议直接建一个索引视图
您这种性能上的表现可否有解释呢？您的索引视图和我实现的方法是差不多的。
#10楼 [楼主] 2008-05-13 11:45 姜敏
@PerfectDesign
居然.
这又是为何?
#11楼 2008-05-13 12:06 小强.假的 [未注册用户]
压力 确实 是数据库的频繁查询. 最好的办法是 缓存..
#12楼 2008-05-13 12:07 假正经哥哥
..
-
sum(case vid3.resource_id is null then 0 else 1 end) as xx
.
from 电影表 info
left join TB_RESOURCE_PRIMARVIDEO vid3 on
info.resource_id =vid3.resource_id
试试上面，你前面引用的话不是的都说的很明白了吗？
一条好的值得称赞的规则是尽量用连接代替所有的子查询 ！！！
#13楼 2008-05-13 12:15 PerfectDesign
@姜敏
指的是你居然用interbase
#14楼 2008-05-13 12:19 brightwang
是不是鸡肋自己可以看看查询计划，没有绝对的好也没绝对的坏，只是应用场合不同
#15楼 [楼主] 2008-05-13 14:48 姜敏
@ 假正经哥哥
..
-
sum(case vid3.resource_id is null then 0 else 1 end) as xx
.
from 电影表 info
left join TB_RESOURCE_PRIMARVIDEO vid3 on
info.resource_id =vid3.resource_id
你的关点和@个人知识管理的
2.子查询作为字段的值