求关于下面的查询语句的优化方案
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这任然是不能接受的
[解决办法]
你们这些高手啊，没事干了是不？
[解决办法]
围观一下
[解决办法]
select g.xs_bm,g.xs_xm,g.xx_bm,s.zy_bm,s.kc_bm
from td_skkb s inner join (select * from t_gdxs where xx_bm='0101') g
on g.xx_bm=s.xx_bm and g.zy_bm=s.zy_bm
[解决办法]
[解决办法]
打酱油的
[解决办法]
为什么不在查询条件上建立聚集索引
CREATE INDEX index_name ON t_gdxs (zy_bm,zy_bm)
CREATE CLUSTERED INDEX INDEX_name ON t_gdxs(xx_bm)
我测试过，聚集索引的选择可能会影响到索引的碎片，
但是在查询条件上建立聚集索引，与造成的碎片相比，是值得的。
[解决办法]
可以了吧，还能优化吗，围观一下
[解决办法]
on ...(xx_bm,zy_bm) include(....) ?
[解决办法]围观
[解决办法]
lu guo
[解决办法]
有点 蛋疼 看书去
[解决办法]
不知道是做什么的数据库，很显然一个数据库的两个表，有两列是存储一样的数据，需要优化一下。
[解决办法]
[解决办法]
[解决办法]
高手啊，甘氨酸
[解决办法]
[解决办法]
看不懂。。。。
[解决办法]
可以拆成两句话的嘛。
我之前试过显示文章栏目及其下级栏目所有文章。
如果用文章表和栏目表inner join 速度还行，不过愿意不如先查出下级的栏目id
然后直接查询文章表。
速度远远超过 inner join 出来的。其实就是减少了很多运算。
[解决办法]
哇，初学数据库，表示看不懂
[解决办法]
在这个xx_bm上面加索引
[解决办法]
5w条数据。直接物理读？？？楼主算算用多少秒。
优化的可能性就只能在那里了。
你直接select一个表5万条数据。是多少？？
一句话。优话个毛。
[解决办法]
表示我完全看不懂！
[解决办法]
学习。学习。
[解决办法]
好东西哦 谢谢谢谢
[解决办法]
学习中,收藏。
[解决办法]
一直也不怎么明白，学习学习！
[解决办法]
learning.
[解决办法]
看虽然看不大懂。但是顶下也好
[解决办法]
有物理读，预读，内存应该是够使的
[解决办法]
学习了。
期待高手。
[解决办法]
呵呵！认真学习了
[解决办法]
create index xxbm_zybm_kcbm_idx on td_skkb(xx_bm,kc_bm,zy_bm)
改为：
create index xxbm_zybm_kcbm_idx on td_skkb(xx_bm,zy_bm,kc_bm)
[解决办法]不是太懂
[解决办法]
..
[解决办法]
路过看看。。。
[解决办法]
