如何让降序排序更高效

[复制链接]
查看11 | 回复9 | 2014-9-10 21:37:07 | 显示全部楼层 |阅读模式
我有一个分页的应用,用降序排序的时候效率不是很好。请看:
[php]
suk@ORACLE9I> create index idx_item_update_date on item(update_date ,item_id);
索引已创建。
suk@ORACLE9I> analyze table item compute statistics for table for all indexes for all indexed columns;
表已分析。
suk@ORACLE9I> select/*+ first_rows */ * from (select* from item where item_type='p' and item_category='mp3播放器' and update_date is not null orde
r by update_date,item_id) where rownum select/*+ first_rows */ * from (select* from item where item_type='p' and item_category='mp3播放器' and update_date is not null orde
r by update_date desc,item_id desc) where rownum select * from (select /*+ index_desc(item idx_item_update_date) */ * from item where item_type='p' and item_c
pdate_date is not null order by update_date desc,item_id desc) where rownum drop index idx_item_update_date;
索引已丢弃。
suk@ORACLE9I>create index idx_item_update_date on item(update_date desc,item_id desc);
索引已创建。
suk@ORACLE9I> analyze table item compute statistics for table for all indexes for all indexed columns;
表已分析。
suk@ORACLE9I> select * from (select /*+ index(item idx_item_update_date) */ * from item where item_type='p' and item_category='mp
_date is not null order by update_date desc,item_id desc) where rownum<=20;
已选择20行。

Execution Plan
----------------------------------------------------------
0SELECT STATEMENT Optimizer=CHOOSE (Cost=67867 Card=20 Bytes=

3537947)
10 COUNT (STOPKEY)
21 VIEW (Cost=67867 Card=721 Bytes=3537947)
32 TABLE ACCESS (BY INDEX ROWID) OF 'ITEM' (Cost=67867 Ca

rd=721 Bytes=339591)
43 INDEX (FULL SCAN) OF 'IDX_ITEM_UPDATE_DATE' (NON-UNI

QUE) (Cost=804 Card=214008)


Statistics
----------------------------------------------------------
96recursive calls

0db block gets
22357consistent gets

0physical reads

0redo size
6472bytes sent via SQL*Net to client
514bytes received via SQL*Net from client

3SQL*Net roundtrips to/from client

0sorts (memory)

0sorts (disk)
20rows processed
--效果依然不理想

..
[/php]
降序索引本质是一个函数索引,但这个效率也太低了
对于这种情况如果做才能更高效呢?
回复

使用道具 举报

千问 | 2014-9-10 21:37:07 | 显示全部楼层
我觉得内层fts,然后sort都没这么大的consistent gets
回复

使用道具 举报

千问 | 2014-9-10 21:37:07 | 显示全部楼层
有可能和数据分布有关……
你先不要加 item_type='p' and item_category='mp3播放器'的条件,再测试一次看看……
回复

使用道具 举报

千问 | 2014-9-10 21:37:07 | 显示全部楼层
看一下update_date 列的histogram
回复

使用道具 举报

千问 | 2014-9-10 21:37:07 | 显示全部楼层
你这样运用降序全索引扫描,性能当然差了,普通索引也可以用降序扫描的,最主要是你的过滤条件与分页的写法有关...
http://xzh2000.itpub.net/post/96/194216
回复

使用道具 举报

千问 | 2014-9-10 21:37:07 | 显示全部楼层
最初由 xzh2000 发布
[B]你这样运用降序全索引扫描,性能当然差了,普通索引也可以用降序扫描的,最主要是你的过滤条件与分页的写法有关...
http://xzh2000.itpub.net/post/96/194216 [/B]

我的测试中也有用普通索引进行降序扫描的,但是效率也不高
回复

使用道具 举报

千问 | 2014-9-10 21:37:07 | 显示全部楼层
最初由 xzh2000 发布
[B]你这样运用降序全索引扫描,性能当然差了,普通索引也可以用降序扫描的,最主要是你的过滤条件与分页的写法有关...
http://xzh2000.itpub.net/post/96/194216 [/B]

學習.
回复

使用道具 举报

千问 | 2014-9-10 21:37:07 | 显示全部楼层
最初由 rollingpig 发布
[B]有可能和数据分布有关……
你先不要加 item_type='p' and item_category='mp3播放器'的条件,再测试一次看看…… [/B]

如果是降序,不加条件的话会很快,
但是如果是升序的话加上条件也会很快
我用不同的item_category测试,效率差别不小,看来就是跟数据分布有关了
这样的话怎么做才能效率更高呢?
回复

使用道具 举报

千问 | 2014-9-10 21:37:07 | 显示全部楼层
最初由 space6212 发布
[B]
如果是降序,不加条件的话会很快,
但是如果是升序的话加上条件也会很快
我用不同的item_category测试,效率差别不小,看来就是跟数据分布有关了
这样的话怎么做才能效率更高呢? [/B]

考虑把 item_category 和 update_time 作复合索引……
回复

使用道具 举报

千问 | 2014-9-10 21:37:07 | 显示全部楼层
你的索引里并没有包含查询条件,索引起到的作用只是避免排序而已,为什么不是试试不使用索引的情况呢?你的表里一共才700条数据,sort一下也不见得有多大的代价
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行