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

热情的菜鸟 2013-10-11 04:02:52
每次执行查询都会卡死,主数据表上的查询条件我都做了索引,有什么办法优化吗?
...全文
3031 65 打赏 收藏 转发到动态 举报
AI 作业
写回复
用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
  • 打赏
  • 举报
回复
引用 48 楼 DBA_Huangzj 的回复:
那就是原因了,用这个select count(distinct autoID)/表的总数把你用到的列都这样查,然后选择值最小那个做第一列,第二小的做第二列,以此类推
扫戴斯乃
發糞塗牆 2013-10-11
  • 打赏
  • 举报
回复
5分之一,筛选性太弱了,不适合做第一列
發糞塗牆 2013-10-11
  • 打赏
  • 举报
回复
那就是原因了,用这个select count(distinct autoID)/表的总数把你用到的列都这样查,然后选择值最小那个做第一列,第二小的做第二列,以此类推
热情的菜鸟 2013-10-11
  • 打赏
  • 举报
回复
引用 46 楼 DBA_Huangzj 的回复:
看上去应该是userID 的筛选性不高,sqlserver选择使用scan,导致性能慢
userID 只有5个,是不是这个原因? 我应该从小往大查?
發糞塗牆 2013-10-11
  • 打赏
  • 举报
回复
看上去应该是userID 的筛选性不高,sqlserver选择使用scan,导致性能慢
加载更多回复(45)

27,582

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 应用实例
社区管理员
  • 应用实例社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧