求解不带条件1.3秒，带条件0.016秒

Question

在测试中，写错代码将SEQ自增长到了60级万，突然发现select * from accounts_roles 这样要1.5-3秒，好吧里面只有5条数据。
手动将SEQ改回来后，依旧发现要很久，但是如果select * from accounts_roles where id>0只要0.016秒。表里只有ID主键，通过触发器ID自增长。
求解怎么怎么才能弄回来百度的下好像要做什么表分析？用的11G。Oracle 11gselect

Answer 1

最后把表删除重新建才解决。只有以后注意所有的查询都带条件了。。过了2天又出现问题了。。测试存储过程弄了个死循环，然后看见序列SEQ在那不停的增长，不知道怎么停下来，只能重启服务。。还好这次没让表出问题，不带条件查询变慢。
在PLSQL里有其他命令或者操作能让存储过程里的死循环停吗。

Answer 2

你的程序只是把SEQ的值变大了吗？没有往表里加入数据吗？

Answer 3

查看下执行计划。两种方式执行有什么不同。可能是因为id>0走的是索引 而没有加条件是走的全表扫描

Answer 4

你的表可能在id上建索引了，条件中带id就走索引，不带id就全表查询，效率差异就体现出来了。

Answer 5

-- 不知道楼主听说过“高水位线”这一说。
-- 你可以简单这么理解：类似于涨潮(或洪水)后，湖面曾经水位最高位置留下的痕迹。
-- 表也有这样的说法，具体请参数：
http://www.cnblogs.com/linjiqin/archive/2012/01/15/2323030.html-- 当你删除表其记录(只剩下5条记录)时，表的高水位线默认是没有变化的，此时，
-- 如果你select * from accounts_roles要走全表扫描，且扫描同样多的数据块，
-- 所以你会感觉执行效率跟没删除记录行时差别不大。-- 而你如果select * from accounts_roles where id>0的时候，表走的是ID主键索引，当然就不太受表的高水位线影响。

Answer 6

楼上分析到位，楼主可以通过收缩或重建表的方式解决空闲空间的问题！----收缩表
alter table accounts_roles enable row movement;--启动行移动；
alter table accounts_roles shrink space cascade;--收缩空间；
alter table accounts_roles disable row movement;--关闭行移动；

Answer 7

高水位被你冲高了，虽然只有5条数据，但全表扫描，是扫描高水位以下所有数据，包括5行数据以外的所有空数据块，shrink一下吧，楼上有代码。