欢迎来到Doc100.Net免费学习资源知识分享平台!
您的位置:首页 > 程序异常 >

大数据量停,查询速度优化,多索引情况

更新时间: 2014-01-05 02:14:50 责任编辑: Author_N1

 

大数据量下,查询速度优化,多索引情况

--参考方法--
看一下查询计划
另外 LID 字段的区分度高吗?
考虑一下在LID 字段上加索引?
--参考方法--
引用:
是说给LID单独加一个索引是么。   我建过索引,基本上没有效果。LID的区分不是很高, 他的值就在1-1000, 大概是这样,一个UID,有1000个LID,由 UID和LID组成的主键。 
另外问下,因为我没给这个表建立主键,是不是加上 UID 和LID作为主键后,会好很多。因为数据在运行,暂时没法建,如果有效果的话,我就停了系统来建立一个。


1)不必麻烦在LID上单独建立索引了、LID会用上复合索引 TDDEMO_INDEX1
2)明白主键的作用就不会这么想了、主键是负责"外交"的、你2个频繁sql都不做关联、没必要建
3)感觉你的sql可优化的空间不会很大了哈、order by UID 已经在索引里面帮你搞好了、这部分没有开销
4)贴上执行计划来看看吧

--参考方法--
1)从你执行计划可以看出、目前你的索引确实没问题了
2)麻烦贴上统计信息?结合执行计划一起分析
--参考方法--
引用:
create index TDDEMO_INDEX1 on TDDEMO (UID, LID)
Select UID, LID, NAME from TDDEMO where UID >= XX and UID <= YY and LID = ZZ order by UID ;
上一篇:上一篇
下一篇:下一篇

 

随机推荐程序问答结果

 

 

如对文章有任何疑问请提交到问题反馈,或者您对内容不满意,请您反馈给我们DOC100.NET论坛发贴求解。
DOC100.NET资源网,机器学习分类整理更新日期::2014-01-05 02:14:50
如需转载,请注明文章出处和来源网址:http://www.doc100.net/bugs/t/7515/
本文WWW.DOC100.NET DOC100.NET版权所有。