难道SQL的子查询就是鸡肋吗？
bsp; from 电影表 info
where 1=1 ";
{
//返回结果
string s="";
string sql=@"select count(vid3.resource_id ) from 电影表 info3
inner join TB_RESOURCE_PRIMARVIDEO vid3 on
info3.resource_id =vid3.resource_id and
info3.resource_id ="+ resource_id;
//执行代码省略
return s;
}
info.resource_id,
字段1,
info.RESOURCE_VOLUMECOUNT,--完整电影应该有多少集
字段2
from 电影表 info
where 1=1 ";
where 1=1 ";
现在换一种方法来做:
下面的语句和上面的语句只有一个区别就是没有查询lastCount字段,但是查询出了info.RESOURCE_VOLUMECOUNT字段（完整电影应该有的集数）,就是说去掉了那个子查询.在绑定数据的时候,通过每次记录的resource_id(电影ID)重新进数据库执行一次以前的子查询,
具体实现是这样的:
在外层记录做循环的时候，通过resource_id来取电影实际存在多少集.在程序中来实现info.RESOURCE_VOLUMECOUNT与"电影实际存在的集数"做减法.这样做也是查询表:电影表总共11次,连接数据库11次.
{
//返回结果
string s="";
string sql=@"select count(vid3.resource_id ) from 电影表 info3
inner join TB_RESOURCE_PRIMARVIDEO vid3 on
info3.resource_id =vid3.resource_id and
info3.resource_id ="+ resource_id;
//执行代码省略
return s;
}
下面是去掉了子查询的SQL查询语句。它是最外层的循环，每循环一条记录后用取得的电影ID再调用上面的方法去计算此电影实际有多少集，这样在功能上就与第一种方法(包含子查询)得到的结果是一样的了。但是在效率上有太大的差距。
info.resource_id,
字段1,
info.RESOURCE_VOLUMECOUNT,--完整电影应该有多少集
字段2
from 电影表 info
where 1=1 ";
理论上说应该是查询表11次打开数据库连接1次的在性能上应该会好很多啊,但是实际不则相反,反而是查询表11次打开数据库11次之多的后一种方法在执行时间上会少很多.不知道这样的子查询在实际数据库操作中到底会有多大的实际用处呢，是否真是鸡肋呢？我在实验的时候当数据特别少时差别不大，一旦多了，哪怕只有1000条，性能上都有特别大的差距，有时会出现死机的状况。我用的是interBase下的firebird数据库，这里不能显示出执行的具体时间，抱歉了。虽然是小型的，但是也能反应出问题来，希望高手们看到了能帮我分析一下其中的原因，我们在查