用Select+Where多条件查询语句，查询一个有100亿条数据的视图。

热情的菜鸟 2013-10-11 04:02:52

每次执行查询都会卡死，主数据表上的查询条件我都做了索引，有什么办法优化吗？

...全文

3099 65 打赏收藏转发到动态举报

写回复

用AI写文章

65 条回复

切换为时间正序

请发表友善的回复…

发表回复

sunbo624 2013-10-12

打赏
举报

datetime别用date类型存了用14位的数字存yyyyMMddhhmmss这种的占用的物理空间少磁盘产生的瓶颈可以小一些

blackkettle 2013-10-12

打赏
举报

测试结果出来了没有？

专注or全面 2013-10-12

打赏
举报

where 条件中不是有时间段条件吗那还不直接在datetime那列上建立聚集索引？性能问题首先要考虑的就是是不是有聚集索引可以用，你说查询没返回结果集，那么用聚集索引就可以直接过滤出来数据了，要别的索引意义也不大

q512362091 2013-10-12

打赏
举报

从来没想过. 单表数据会达到这个数量级别. 应该考虑分区历史表. 切割下.

LongRui888 2013-10-11

打赏
举报

其实你建的索引，要把帅选性最高的字段放在前面，像那个autoId可以放后面的。

發糞塗牆 2013-10-11

打赏
举报

明天我不上班，不过有时间我还是会上的，从2008开始，where条件的顺序就不再有这么严格的要求，一开始没想到，所以都把帖子刷到60楼了，作为一个DBA，失败啊

热情的菜鸟 2013-10-11

打赏
举报

引用 58 楼 DBA_Huangzj 的回复:

一般建议：自增字段做索引第一列，因为唯一性最高，然后才按照刚才给你的count语句来排其他字段。

OK，明天发结果。

發糞塗牆 2013-10-11

打赏
举报

一般建议：自增字段做索引第一列，因为唯一性最高，然后才按照刚才给你的count语句来排其他字段。

热情的菜鸟 2013-10-11

打赏
举报

那是个自增长字段

热情的菜鸟 2013-10-11

打赏
举报

引用 55 楼 DBA_Huangzj 的回复:

验证一下我的想法是否正确

我把数据都删了，重建了索引，明早过来又是好几亿的数据，我测完给你发结果。还想问下，App_Data表中的autoID是否影响我的查询？需要调整吗？

發糞塗牆 2013-10-11

打赏
举报

验证一下我的想法是否正确

發糞塗牆 2013-10-11

打赏
举报

我想知道现在效率如何？

热情的菜鸟 2013-10-11

打赏
举报

引用 52 楼 DBA_Huangzj 的回复:

值改变的话影响不大，不过有可能出现参数嗅探等问题，你最起码要保证顺序不变。

感谢你感谢楼上的每一位朋友

發糞塗牆 2013-10-11

打赏
举报

值改变的话影响不大，不过有可能出现参数嗅探等问题，你最起码要保证顺序不变。

热情的菜鸟 2013-10-11

打赏
举报

引用 49 楼 DBA_Huangzj 的回复:

5分之一，筛选性太弱了，不适合做第一列

太感谢了，顺便问下，我这个筛选条件语句会随着客户的不同选择而变化，比如： WHERE (userID = 1) WHERE (devID = 1) WHERE (userID = 1)AND (devID = 1) 等等组合都有可能出现，但字段的前后顺序是不变的，请问这样的情况还需要特别关注索引的顺序吗？

热情的菜鸟 2013-10-11