关于整理索引后查询效率的有关问题[]
关于整理索引后查询效率的问题[在线等]
问题是这样的
有一个有7张表参与的查询,大体结构如下:
select a.*,b.X,c.X
from (select distinct yyy from ...) a
cross join
(select distinct xxx from ....) b
crosss join
(select .... from ....) c
子查询a单独查询出14行
子查询b单独查询出53行
子查询c单独查询出68行
我在用语句整理这几个表之前,查询用时1秒,查询出5万多行
整理后用时10秒,同样是5w多行数据,但整理后的执行计划却变了
变化在于整理前b子查询位于最后一步,行计数显示700多行,占8%
整理后b子查询还是位于最后一步,但行计数显示却是666400行,占到23%,下一步的distinct操作占到60%
这让我非常郁闷,不知从何下手,貌似整理前三个子查询是查完后才cross join的
整理后好像是先cross join,着效率肯定高不了,求各为老师指点!!
------解决方案--------------------
七个表查询?玩得也太高雅了.
帮顶.
------解决方案--------------------
感觉b不应该是最后一步，
select distinct yyy into #a from ...
select distinct xxx into #b from
select .... into #c from
select a.*,b.X,c.X from #a a cross join #b b cross join #c c
drop table #a,#b,#c
试一下。找出哪个环节慢
------解决方案--------------------
查看一下运行计划;
exec showPlan_all on
------解决方案--------------------
换种方法来做呢
------解决方案--------------------
up...
------解决方案--------------------
偶发了一贴优化数据库
http://community.csdn.net/Expert/topic/5428/5428951.xml?temp=.6007959
------解决方案--------------------
索引重建最好不要太頻繁，肯定會影響性能的
物理位置也會發生改變的
问题是这样的
有一个有7张表参与的查询,大体结构如下:
select a.*,b.X,c.X
from (select distinct yyy from ...) a
cross join
(select distinct xxx from ....) b
crosss join
(select .... from ....) c
子查询a单独查询出14行
子查询b单独查询出53行
子查询c单独查询出68行
我在用语句整理这几个表之前,查询用时1秒,查询出5万多行
整理后用时10秒,同样是5w多行数据,但整理后的执行计划却变了
变化在于整理前b子查询位于最后一步,行计数显示700多行,占8%
整理后b子查询还是位于最后一步,但行计数显示却是666400行,占到23%,下一步的distinct操作占到60%
这让我非常郁闷,不知从何下手,貌似整理前三个子查询是查完后才cross join的
整理后好像是先cross join,着效率肯定高不了,求各为老师指点!!
------解决方案--------------------
七个表查询?玩得也太高雅了.
帮顶.
------解决方案--------------------
感觉b不应该是最后一步，
select distinct yyy into #a from ...
select distinct xxx into #b from
select .... into #c from
select a.*,b.X,c.X from #a a cross join #b b cross join #c c
drop table #a,#b,#c
试一下。找出哪个环节慢
------解决方案--------------------
查看一下运行计划;
exec showPlan_all on
------解决方案--------------------
换种方法来做呢
------解决方案--------------------
up...
------解决方案--------------------
偶发了一贴优化数据库
http://community.csdn.net/Expert/topic/5428/5428951.xml?temp=.6007959
------解决方案--------------------
索引重建最好不要太頻繁，肯定會影響性能的
物理位置也會發生改變的