在已经给WHERE字段添加索引，分页查询效率还是慢的情况下有什么方法检查或提高性能？
0
悬赏园豆：20
[已解决问题]
解决于 2019-06-05 21:55
ID Price SourceUrl SourceSite InsertTime ProName State
我有一张这样的表，总数据有3千万，由于要按时间条件来查询数据，所以用了InsertTime做索引条件
但是在使用ROW_NUMBER分页的时候效率还是很低，想问下有什么更好的方法来提升效率
或者说下什么方法来检查效率低的问题，应该如何去检查
WITH cte AS ( SELECT ROW_NUMBER() OVER(ORDER BY ID) as rownum, * FROM MyTable WHERE 1=1 AND InsertTime>='10/8/2014' AND InsertTime<'4/2/2015' ) SELECT * FROM cte WHERE rownum>=1 AND rownum<=20
最佳答案
0
不要用with cte
cte会临时查询出3千万，直接组合查询语句返回分页数量，很快的，至少我的2亿的表简单查询分页没有性能问题
收获园豆：5
SELECT * FROM ( SELECT ROW_NUMBER() OVER(ORDER BY ID) as rownum, * FROM MyTable WHERE 1=1 AND InsertTime>='10/8/2014' AND InsertTime<'4/2/2015' ) AS t WHERE t.rownum>=1 AND t.rownum<=20
你是指这样处理吗，但是我用过执行计划看过，我的两条语句都是50%的消耗
@最佳损友:
尽量别用*号，其次查询语句加上with(nolock)
SELECT ROW_NUMBER() OVER(ORDER BY ID) as rownum, * FROM MyTable with(nolock)
id，InsertTime确保加上了索引
如果还是慢，那基本上就可以定位硬件问题了
另外3千万的数据量如果是sqlserver的话其实有点多了，三千万的数据相信没人能看的过来，尽量使用多策略的数据，是否需要保存这么多，长时间不用的数据可以做归档等等
其他回答(3)
0
聚集索引是建在ID字段上的吗？
收获园豆：5
对的，聚集索引是建在ID上的
@最佳损友: 如果按InsertTime进行排序是可以接受的，建议将聚集索引建在InsertTime字段上试试，然后 ORDER BY InsertTime 。
@最佳损友: 你的剩余园豆不够提高悬赏
0
1、升级硬件，数据库服务器CPU和内存升级，外加更好的网络带宽
2、InsertTime如果是唯一的，聚集索引建立在InsertTime字段而不是ID上（同dudu）
3、按时间进行分区
4、全文检索，常用技术如lucene,elasticsearch等
5、改变查询策略，分页给个虚数，比如固定按时间条件查询n条，分m页（其中m是个虚数，实际不知道具体几页），用户很少真的看很多页
收获园豆：5
0
正如dudu与JeffWong所说，时间维度的查询，既然估计改聚集索引主键不太可能，最应该做的是按时间（年或季度）分区。
收获园豆：5
