排序与分布

本帖最后由 qingyun 于 2013-6-16 21:48 编辑

做查询的时候
1.如果没有分页，在记录特别多的时候，显示会很慢；
2.如果数据实在太多，比如几百万到几千万甚至上亿(我遇到的大部分数据量大的都在几百万条)，分页前通过select count(*) from table 获取记录条数，也不明智；
   因为几百成千万条的数据统计一下记录数可能也要10秒左右；
3. 记录特别多，最好不要做排序，一旦排序特比慢：


比如：有一张表 LOGIN_LOG  ，里面有600多万条数据：


1. 执行 select count(1) from login_log 要12秒；

  2.按1000条记录一页分页，看第2页(不排序)，要 0.2秒(够快了，用户体验不错，缺点就是分页的数据是乱的，没有排序)
SELECT * FROM (SELECT A.*,ROWNUM RN  FROM (SELECT * FROM LOGIN_LOG ) A WHERE ROWNUM <= 2000)
WHERE RN >= 1001





3.按1000条记录一页分页，看第2页(排序)，要 14秒(虽然排序正确了，可是10几表的等待实在无法忍受)
SELECT * FROM (SELECT A.*,ROWNUM RN  FROM (SELECT * FROM LOGIN_LOG order by 1 ) A WHERE ROWNUM <= 2000)
WHERE RN >= 1001


所以我的做法是：

   1.不默认显示页数(因为要做可能很费时间的select count.. ),只显示“上一页 ，下一页 ”两个按钮，如果操作员实在想看多少页，再手工点“显示页数”按钮；
   2.不做SQL排序，在客户端上，点击Grid的标题排序(客户端 DataSet 自身排序，和 SQL 没关系)，这个排序只对当前页有效；也就是排序在前台做，不在后台做；
    

因为实际操作中，有的客户喜欢一上来就什么条件都没有输入进行查询，或者输入的条件特别大众（比如: 单号 like '%1%'）,这样就必然有大量满足条件的数据，所以弄个不排序的分页，既能给客户看到数据，也能很快的展现；尽管显示的第一页很可能不是客户想要的数据；
  但随着客户再次输入准确的条件，会把数据量缩小到一个比较小的范围，如果1000条一页，那么大部分时候应该是第一页就满足了，不需要看第二页；
这样就是一个相对折衷的方法；

而且大数据的order by 非常伤害 TEMP 表空间，会把它“撑”的很大，缩小不下去，并且如果多个回话并发做大数据的order by 会严重影响数据库的性能的；

既用户第一次进入系统，分页查询时，不进行分页处理。