分页查询大数据量越往后越慢如何解决及索引如何构建比较合理？

Question

本帖最后由 liuli_ping 于 2013-06-28 16:24:36 编辑

Answer 1

直接跑plsql的分页语句，看看影响速度是在hibernate还是sql问题

Answer 2

起初是在项目测试过程中出现慢的问题，后来干脆直接把语句在plsql下跑，结果发现同样存在类似延时问题，基本排除Hibernate的问题；现在是想优化索引，但是就这个查询语句，有where条件，并且有order by排序，如何建立索引比较合理（目前已经把表里的10来字段都单独建立了索引，还是慢），是不是需要把几个字段组合在一起做一个索引，生成组合索引之类的？

Answer 3

查看下执行计划
t.state=1 and t.h_fid='5a4ca4a22a74f721012a7dcf16890013' 这个查询条件选择性如何？如果把大部分的数据都查出来，那就用不了索引。

Answer 4

刚刚接触Oracle，很多术语都不懂，你所指的“执行计划”，是否是在plsql执行查询语句后，按下F5可以查看，如下图：
这个是如何看的？
不过可以看得出644799是符合本次查询条件下的记录总数，数据库中一共有差不多130万条记录。

Answer 5

你这也是查看执行计划的一种方法，它并没有用到索引，而且也不能用索引（查询条件的选择性太差），所以你建索引是没有效果的。
如果你这个业务比较关键且有足够的SGA，可考虑把表CACHE到BUFFER_CACHE中，提高查询效率。

Answer 6

你看一下这篇文章，也许有帮助！
http://blog.csdn.net/yangzhawen/article/details/7661776

Answer 7

SGA术语第一次接触，检查了一下测试机的SGA，如下：以上信息是否代表有足够的SGA？那如何把表CACHE到BUFFER_CACHE中呢？这样一来能否保证在实时修改、删除记录时磁盘里的信息变动后CACHE里的信息也能够及时得到同步或更新？还望能够更深入指点一下，谢谢！
按照文章所述，已调整为708M，问题还是没得到解决。

Answer 8

求记录数没必要用order by t.ss_fid, t.ss_hs_fid, t.login_time既然知道记录数你就知道你要检索的是前半部分还是后半部分，
前半部分： where rownum <= 1000720) where rownum_ > 1000701
后半部分： where rownum_ > 1000701) where rownum <= 1000720具体好不好用俺也不知道，你可以试试

Answer 9

按照你的提示，尝试不用order by t.ss_fid, t.ss_hs_fid, t.login_time：第一次查询时，无论是select *查记录，还是select count(*)统计，依然是挺耗时，分别是22秒和5秒，但是第二次查询相同分页数据时，基本都能控制在0.5到0.7秒以内，这个是不是得益于缓存？如果是，那如何用缓存来解决或是缓解因为增加order by而带来的负面性能影响？

Answer 10

t.state和 t.h_fid 建立组合索引