分页后sql慢了

husthxd

最初由 QYL 发布
[B]是java ，但是我们中间有ejb这一层，不能直接页面从数据库取数据。 [/B]

我意思是后台通过ResultSet的游标移动到需要读取页的开始记录处读取需要读取的记录数然后以值对象List或者HashMap List的形式返回给前台.

QYL

我来的时候，我们的软件已经开发了很多，因此不能随便改动，我们的数据字典很多查询都要用到。很多业务查询都要用到这个表。因此如果创建一个索引，与会影响到很多业务。并且这个表的纪录又170万左右。这个表已经放到cache里边了。

rwq_

最初由 QYL 发布
[B]我来的时候，我们的软件已经开发了很多，因此不能随便改动，我们的数据字典很多查询都要用到。很多业务查询都要用到这个表。因此如果创建一个索引，与会影响到很多业务。并且这个表的纪录又170万左右。这个表已经放到cache里边了。 [/B]

个表的纪录又170万左右。这个表已经放到cache里边了？？？？不会吧，上百万记录放在CACHE里？

QYL

呵呵，我们内存16G，并且这个表用的太多了。没有办法

Puber

最初由 胡一刀 发布
[B]

不太理解，既然是数据字典，就应该是相对静态，
而且经常用到的，为什么反而不要索引，要求全表扫描呢？
是不是把整个表都keep在内存了？
这个表看样子不小，这样好吗？
哪位介绍一下 [/B]

因为Oracle在做parallel query时会用CBO来生成execution plan.
根据你设置的并行度CBO认为用full table scan成本更底的话, 就会用full table scan这种access path.

具体到你所述:
如果表PUB_ITEM_MASTER  A上,如果WHERE中的以下
A.ENTERPRISECODE = 'shjt'条件所涉及的字段上没有索引, 当然会对此表作full table scan.

如果有索引,但表很小的话,CBO得出full table scan的成本低于index unique scan或index full scan的话也会使用full table scan(这主要和db_file_multiblock_read_count参数,及select的列不在索引中有关).

如果表很大的话,CBO使用full table scan只能说明CBO认为使用此索引的selectivity很低.

Fenng

建议阅读一下Rudolf的那个分页的贴子



http://www.c noug.org/viewthread.php?tid=38&highlight=%B7%D6%D2%B3

注意处理一下上面的链接