请问对几百万级数据量 Order by 主键 查询如何优化啊？

数据库版本：11g

数据量：8百万
使用语句
SELECT * FROM oe.product_information ORDER BY PRODUCT_ID DESC;
Select出500行需要40s左右，怎么优化啊？



解析计划如下：


表结构


product_id为主键

15 个解决方案

#1

Select出30行用了41s

#2

该回复于2016-12-29 21:46:38被版主删除

#3

要查出所有的数据吗？ 那用不用索引就没什么意义了；

你是不是要做分页？

#4

什么条件都没有，然后对800万数据做order by，怎么优化都快不了。
真正的需求场景是什么啊。
是否可以加入过滤条件，是否可以做分区等等要根据业务需求判定

#5

需要多少就取多少，不要全部取出吧

#6

引用 4 楼 jdsnhan 的回复:

什么条件都没有，然后对800万数据做order by，怎么优化都快不了。
真正的需求场景是什么啊。
是否可以加入过滤条件，是否可以做分区等等要根据业务需求判定

@jdsnhan 这只是我自己学习的一个测试表，所以没什么实际需求
但是我发现一个问题

SELECT * FROM oe.product_information WHERE product_id < 50000 ORDER BY PRODUCT_ID DESC--大概有4万多

select出30行大概用了15-20s

SELECT * FROM oe.product_information  WHERE  product_id > 50000 ORDER BY PRODUCT_ID DESC ---大概有800万多数据

select出30行结果几乎是秒出
第一个句子的product_id<50000是不连续递增的，即可能是1,2,4,5,7,8.....而>50000的所有product_id是连续递增的。
为什么会有这种差别？

#7

引用 3 楼 wmxcn2000 的回复:

要查出所有的数据吗？ 那用不用索引就没什么意义了；

你是不是要做分页？

谢谢版主，能不能帮忙看下上面的问题

#8

引用 5 楼 fengsuiyingdong 的回复:

需要多少就取多少，不要全部取出吧

嗯

#9

引用 7 楼 u012557814 的回复:

谢谢版主，能不能帮忙看下上面的问题

数据量少了，自然会快一些，跟号码是否连续，也没什么关系；

#10

帮顶！

#11

帮顶

#12

数据库有缓存。
你学习用的数据库应该是不常访问吧，通常缓存是空的。
第一次查询要读硬盘，比较慢。
而且大量读取后（第一次查询结束数据库有空闲），数据库“估计”你还要用到该表，会尽量把你还没访问过的数据也随后读入缓存。
后面的查询都是直接从缓存（内存）中取，所以很快。

一般测试性能，同一个查询反复运行几次，前几次耗时差别很大的不算。

#13

引用 6 楼 u012557814 的回复:

Quote: 引用 4 楼 jdsnhan 的回复:

什么条件都没有，然后对800万数据做order by，怎么优化都快不了。
真正的需求场景是什么啊。
是否可以加入过滤条件，是否可以做分区等等要根据业务需求判定

@jdsnhan 这只是我自己学习的一个测试表，所以没什么实际需求
但是我发现一个问题

SELECT * FROM oe.product_information WHERE product_id < 50000 ORDER BY PRODUCT_ID DESC--大概有4万多

select出30行大概用了15-20s

SELECT * FROM oe.product_information  WHERE  product_id > 50000 ORDER BY PRODUCT_ID DESC ---大概有800万多数据

select出30行结果几乎是秒出
第一个句子的product_id<50000是不连续递增的，即可能是1,2,4,5,7,8.....而>50000的所有product_id是连续递增的。
为什么会有这种差别？

第一个句子的product_id<50000是不连续递增的
===>sorry， 是非递增。1000-2000这个区间的product_id无序

#14

引用 12 楼 Tiger_Zhao 的回复:

数据库有缓存。
你学习用的数据库应该是不常访问吧，通常缓存是空的。
第一次查询要读硬盘，比较慢。
而且大量读取后（第一次查询结束数据库有空闲），数据库“估计”你还要用到该表，会尽量把你还没访问过的数据也随后读入缓存。
后面的查询都是直接从缓存（内存）中取，所以很快。

一般测试性能，同一个查询反复运行几次，前几次耗时差别很大的不算。

< 50000 的那条sql的解析计划 =====全表扫描


>50000的那条sql的解析计划======范围索引扫描


其实就<50000里边有部分product_id是无序的。> 50000的依次+1递增的。
这是导致了解析计划的不同的原因吗？

#15

<50000
记录是按照主键次序存放的，反正要全部字段返回，所以直接顺序读取，一直到发现 >=50000 的记录为止。

>50000
就必须用索引定位了，无法直接读取。