sqlserver2005，1690万的数据量怎么快速分页查询

我现在工作的时候，遇到了一个问题
有一个日志A表，有1690多万数据，而且还可能继续增加，现在要对它进行多个字段，多种方式的分页查询显示，我发现仅仅只有一个字段where就用一两分钟，程序最后当然挂掉了
 后来，用对其中一个用了索引，咧有所改善
 我想到分区，但是发现很拉手，各位多出出意见？
 像这种大数据量的单表查询，怎么样才最快，听说可以横向表分区，怎么搞？

这种量大的数据，通常用分区很有帮助。数据库原来是平衡树，我们自己也可以将分区表用平衡树算法划分（用存储过程实现，这个是可以的），那么在建立适当的索引，因为数据库查询的时候是用平衡树查询的，这样，查询时间可以减少很多

为什么要用BI呢.此时就适应这样的场合.

把指标建事实表,再把分析做成维度表,建多维立方体(Cube),利用OLAP引擎,让它慢都难。

【要对它进行多个字段，多种方式的分页查询显示】
这样，分区表只能照顾一种方式，很难兼顾多种方式，除非你的多种方式都是基于一种排序方式

【而且还可能继续增加】
那就是说增删改不是很频繁的？可否每次增删改后，生成多种对应不同方式的排序结果表（只有行号、原id这样的2个字段），以后的查询只针对这些表，得到所需的那一页的id了，再到主表（按id分区）关联得到那一页的业务数据

1690多万也算平常了
你要去分页 最后做出来的效果也很差.

我认为 任何人无法从1690多万条明细记录里找到金子 反而容易迷失方向
所你以你不需要把这些明细数据都显示给客户。

而是有一些 时段或者区域 来过虑 得出汇总的报表。
从这些汇总报表中 如果客户有疑问 再查其中的部分数据
这样就大大减少了 查询的数据范围。
where 条件中的 字段 要建好相应的索引。
（有人说 数据库95%的性能问题可以通过索引来解决）
号称什么千万级的分页存储过程之类的东东 还是少用为妙 不需要啊.
如果查询的数据都是最近的数据的话 那么尝试把老数据从该表中转移走 这样表记录就少啦 
还有就是查询语句的问题啦 找个高手帮你看看查询语句能不能改写得更高效一些

给你淀清认识上的误区先,"仅仅只有一个字段where就用一两分钟，程序最后当然挂掉了",挂掉的原因不是看是否仅仅只有一个字段,它影响的是I/O加载,另外还要看where怎么写,有没有走索引,以及where后,实际的数据量是多少,就比如,你这个表虽然这么大,但是where id=1这样写和where id<10000000区别非常大,假设它们都走索引了!

所以,对其优化确保两个方面:
1/走索引,
2/数据分散到不同的磁盘I/O,并尽量在需要设计上,对返回结果进行控制,保证在一个合理的数据级上.现实中,即使按需求需要返回100W行数据,但是,返回这么多数据对用户而言有用吗,他看的完吗?所以即符合结果的有这么多量,你的数据库只需要呈现100行?然后指示用户在再一次中查看下100行.

个人感觉，对千万级的表进行分页查询，用户是否看地过来，如果按10条一页的话，需要有百万页 所以，是否可以考虑转换用户的需求； 如果实在不能转换，是否可以考虑不实时提供数据，有一个定时服务，将汇总的数据导入到新表中，查询在新表做，呵呵，优点类似BI了； 实在实在不行，看看分区表能不能提高性能，但是页数还是很多吧

来源：nba直播