数据查询分页显示的优化方法

现有方法：

 

         开始时间 [@start_dt ]   结束时间 [@end_dt ]

         其它条件 [      ]

查询数据总量：[XXXX]

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

 

缺点：

如果有1000 数据，每页显示50条，就要显示 20个页连接。

查询需要先查询一个数据总量：

db.coll_name.find({date:{$gt:@start_dt,$lte:@end_dt}}).count()

再查询明细数据：

db.coll_name.find({date:{$gt:@start_dt,$lte: @end_dt}}).skip(@pageno-1).limit(50)

 

         当查看页数越来越大时，skip(@pageno-1) 越大，性能越差。

 

 

优化方法：1 （以前提出过）

 

为了减少无效的查询数据返回，应用页面中，@start_dt, @end_dt两个值默认值范围为1周，或是半个月，减少一次的查询量。

这个修改，只是在不用修改页面布局，修改简单。

以前在没有默认值的情况下，用户一选就是一个月，几个月的情况，后面的查询等待就几十秒。。。

更恶心的是每个页面默认了一个月的查询范围，页面一打开就自动查询跑结果。弄得页面打开特别慢，用户体验很不好。

（打开页面不自动查询，让用户选择要查询的范围，再点击再查询，相对就好了不少）

 

优化方法： 2

         页面不显示所有数据的页面连接,也不显示查询数据的总量，查询时只查询 每页数量 50 +1

db.coll_name.find({date:{$gt:@start_dt,$lte: @end_dt}}).limit(51)

如果有51条记录，

页面显示表格 下方 显示 [下一页]。点击下一页翻看后面数据

 

 

查询数据总量：[XXXX]

[下一页]

优点：返回数据量小

缺点：

点击 [下一页] 后，如果能用精确定位到某一条记录，比如：

db.coll_name.find({date:{$gt: @start_dt,$lte: @end_dt},_id:{$gte:@no_51_id}}).limit(51)

_id 大于等于 刚才查询的第51条记录的_id 值。

 

如果不能精确定位到某一行，比如只能用时间字段值 { date :{$gte: @no_51_date}}，可能会有不准确的问题。

 

 

优化方法： 3

 

         这个方法可以说是上面两种的折中。第一次只查询201条记录

db.coll_name.find({date:{$gt:@start_dt,$lte: @end_dt}}).limit(201)

 

         如果返回总数小于这个数，那么显示页下方不显示 [更多]，如果有201条，显示

 

本次查询数据总量：[200]

 

1  2  3  4  更多

 

这个方法很巧妙的告诉用户,一次只查了201条记录，需要更多，还可以查看。

同时返回数据量也减少到了201

第二次查询如下：

db.coll_name.find({date:{$gt: @start_dt,$lte: @end_dt}}).skip(200).limit(201)

只需要记录一个变量值： （点击了几次[更多]，用来记录要skip 多少数据。其实用户不会一直翻页，翻更多的页，还不如减小查询范围）

 

优点：用户体验好，对现有的修改也不大，返回数据量也小       

缺点：但如果翻页越来越多，性能还是会变差。