文章表结构如下table file{
id bigint [PRIMARY] not null,
ttile ntxt, 约束1 default''
content ntxt, 约束2 default''
pubtime datetime
}
其中id是聚集索引,非自增。目前表中记录是1千万,但是id值是跳跃的从100000000(1亿)开始到100000000000(千亿),中间并不连续,可能好几十亿是没有的。(别问为什么,历史)现在每次抽取1000条数据 select top 1000 id,title,content,pubtime from file where id>=100000000 and id <=100000000000 order by id
其中id>=100000000这个值每次都取上次1000条的Max(id)
每次抽取的时间平均都在30s以上,机器是双核2.6,2G内存的服务器,请问各位有何好的解决办法?

解决方案 »

  1.   

    首先 2G内存是比较弱的。1000W数据最起码要8-16G内存。
    第二:这个聚集索引有问题。
    可以考虑用pubtime+ID作为组合键,作非聚集索引。
    参考:
    http://www.cnblogs.com/downmoon/archive/2010/02/04/1663956.html
    第三:itle,content都是ntxt,会影响速度
      

  2.   

    看看你的内存有没有page out的情况...
    一般不会这么慢的...主要是看你的索引的情况,可能需要整理了...
      

  3.   

    感谢大家,查看了下任务管理器,cpu使用一直在1%-2%之间,内存使用1.6G左右(好几个程序在跑),中午加了下with(nolock),因为有别的程序还在往里写入,担心锁的问题。但是效果一般没有太大变化。修改索引的话,在管理器中,因为数据量比较大,总是修改不成功(超时)。不知道有无好办法。
      

  4.   


    lz可以考虑用下索引视图!把这部分top 1000 id的数据固化。
      

  5.   

    另外补充下,id>xxx,这个xxx是当参数传递进去的,保证已经处理过的id不再处理
      

  6.   

    先测试下
     select top 1000 id,pubtime from file where id>=100000000 and id <=100000000000 order by id 
    多少时间?
      

  7.   

    ttile ntxt, 约束1 default'' 
    content ntxt, 约束2 default'' 
    这两个ntext,一般情况下长度多少?
      

  8.   

    select top 1000 id,pubtime from file where id>=100000000 and id <=100000000000 order by id 这个时间和其他的取1000条时间差不多。基本都是30-60s内。content的长度一般都在5000以上。下面是这个表的索引扫描情况:
    - 扫描密度 [最佳计数:实际计数].......: 19.53% [66394:339915]
    - 逻辑扫描碎片 ..................: 81.97%
    - 区扫描碎片 ..................: 74.21%不知道是不是碎片太多的问题?有何良策可以快速重建索引?我尝试copy表30分钟only copy 4w条数据,只好放弃。
    在表结构不能调整,机器配置不能增加,业务不能几小时中断的情况下。
    如果是这个原因
    只能等下次升级时解决了。