求关于下面的查询语句的优化方案

[开着拖拉机泡妞]

select
	g.xs_bm,
	g.xs_xm,
	g.xx_bm,
	s.zy_bm,
	s.kc_bm
from
	td_skkb s 
inner join 
	t_gdxs g 
on
	g.xx_bm=s.xx_bm
	and g.zy_bm=s.zy_bm
where
	g.xx_bm='0101'

go

SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。

/*
(593527 行受影响)
表 'Worktable'。扫描计数 69，逻辑读取 113303 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'TD_SKKB'。扫描计数 1，逻辑读取 5 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'T_GDXS'。扫描计数 1，逻辑读取 353 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

SQL Server 执行时间:
CPU 时间 = 2375 毫秒，占用时间 = 7973 毫秒。
*/

说明:表td_skkb有1.5万条数据左右，表t_gdxs有250万条数据左右 满足条件的xx_bm='0101'的大概有5.5万条数据

我之前的索引:
create index xxbm_zybm_kcbm_idx on td_skkb(xx_bm,kc_bm,zy_bm)
go
create nonclustered index xxbm_xsbm_zybm_xsxm_idx on t_gdxs(xx_bm,zy_bm)include (xs_bm,xs_xm)
go

没创建这两个索引之前耗时16s，现在耗时8s这任然是不能接受的

[yzsind]

SQL Server 执行时间: CPU 时间 = 2375 毫秒，占用时间 = 7973 毫秒。 整个SQL没有物理读取，说明不存在磁盘开销，全是逻辑读，逻辑读就是CPU时间，而CPU开销远小于总时间，说明还有许多时间不在CPU和磁盘上，应该是在网络上。 楼主这个案例，从SQL上讲已经很优了，性能瓶颈在数据网络传输到客户端，60W条记录传输到客户端需要很长时间。 建议评估一下是否真的需要这么多数据一次性返回给客户端。

[yzsind]

引用 26 楼 TravyLee 的回复:

引用 23 楼 lixzhong 的回复:create nonclustered index xxbm_xsbm_zybm_xsxm_idx on t_gdxs(xx_bm,zy_bm)include (xs_bm,xs_xm) 这个索引不给力 select * from t_gdxs where xx_bm='0101' 这条单独执行 要多久? SQL cod……

你这个单表访问需要590ms，5.5W记录，性能瓶颈也是在网络上. 最终你两个表JOIN要返回59W条记录，所以需要7s钟是正常了.

[PB菜鸟]

引用 28 楼 SQL77 的回复:

create index xxbm_zybm_kcbm_idx on td_skkb(xx_bm,zy_bm)include(kc_bm) gocreate nonclustered index xxbm_xsbm_zybm_xsxm_idx on t_gdxs(xx_bm,zy_bm)include (xs_bm,xs_xm) go 索引列要对齐。 还有给SHOWPLAN_TEX……

create index xxbm_zybm_kcbm_idx on td_skkb(xx_bm,zy_bm)include(kc_bm) 用这个试试，包含性列加上查询条件。

[wch007]

恩,学习了..

[savie_lee]

学习一下》》》》》》》》》》》

[Jacking_Liu]

弱弱地问一句楼主：td_skkb表有多少行数据是xx_bm='0101'的？这个对查询策略比较重要。如果xx_bm的值很随机，那为什么在inner join数据之前，尽量地过滤掉没必要的数据呢？如果td_skkb只有一行数据是xx_bm='0101'的话，做出优化后就可以减少inner join的数据集合规模。

[Jacking_Liu]

引用 146 楼 u112245 的回复:

弱弱地问一句楼主：td_skkb表有多少行数据是xx_bm='0101'的？这个对查询策略比较重要。如果xx_bm的值很随机，那为什么在inner join数据之前，尽量地过滤掉没必要的数据呢？如果td_skkb只有一行数据是xx_bm='0101'的话，做出优化后就可以减少inner join的数据集合规模。

补充一下我的思路：

select
    g.xs_bm,
    g.xs_xm,
    g.xx_bm,
    s.zy_bm,
    s.kc_bm
from
    td_skkb s 
inner join 
    t_gdxs g 
on
    g.xx_bm=s.xx_bm
    and g.zy_bm=s.zy_bm
where
    s.xx_bm = '0101' and
    g.xx_bm='0101'
 
go

第15行是过滤掉td_skkb表的多余数据。 强烈各位数据库同仁们多看看《SQL语言艺术》一书，书中说的比较通俗易懂，鞭辟入里。

[wsczh19920426]

没必要优化了吧

[Edward_S_Y]

只能学习了 看看还是可以的 ………………

[hutamam]

[code=php]

[/code]

[zhaoshibojh]

[zhengnan2012]

#127楼说用left join 代替 inner join ?这还会更快？我擦，你还好意思批评人家。

[dpchy]

学习了！！！！！！！！！！！！！

[huang17m]

真不懂。。。。。。。。

[无敌洋葱头]

围观一下下

[zjh_c_s_d_n]

围观。。。。

[卡胖]

路过看看、、

[wpycs]

这优化个蛋,用top语句把结果分页查询

[普世编程技术]

引用 126 楼 MSTOP 的回复:

引用 98 楼 linustd 的回复:引用 55 楼 MSTOP 的回复:索引,表 碎片整理. 终于逮住一个所谓的高手, 还版主? 这SQL明明是IO瓶颈, 还索引,还碎片整理. 哥们, 你和那些被微软套牢的, 自认为自己懂得新技术, 实际上基本功一塌糊涂的软奴一个样. 回家看看基本功吧. 计算机软件从上个世纪80年代以来就从来没有诞生过新技术,……

孙子, 这里的IO瓶颈不是数据库里的IO, 是你妈的查询出结果, 把数据传送到你的客户端的IO 你妈逼的64K的网速看高清电影, 卡的要死, 难道你挂人家服务器的IO有问题>?

[华芸智森]

SB这口气一看就是什么电脑培训班出来的货.还他娘的装B.还他妈的在这里JJYY....CAO...