有条语句在测试的时候，发现其走全表扫描，而按道理它应该走索引才是最优的。

select">ops$admin@AEPDB>select * from (select row_.*, rownum rownum_ from (
SELECT *
FROM udb.xxxx h
WHERE h.STATUS = '0' and h.LOCK_USER is not null and h.gmt_register>to_date('1900-1-1','yyyymmdd')
order by h.GMT_REGISTER DESC) row_ where rownum <= 6) where rownum_ >= 1;

============
Plan Table
============
-------------------------------------------------------+-----------------------------------+
| Id | Operation | Name | Rows | Bytes | Cost | Time |
-------------------------------------------------------+-----------------------------------+
| 0 | SELECT STATEMENT | | | | 14K | |
| 1 | VIEW | | 6 | 432 | 14K | 00:03:58 |
| 2 | COUNT STOPKEY | | | | | |
| 3 | VIEW | | 1300K | 75M | 14K | 00:03:58 |
| 4 | SORT ORDER BY STOPKEY | | 1300K | 22M | 14K | 00:03:58 |
| 5 | TABLE ACCESS FULL | UDB_RANDOM_PASSPORT| 1300K | 22M | 7299 | 00:01:28 |
-------------------------------------------------------+-----------------------------------+
Predicate Information:
----------------------
1 - filter("ROWNUM_">=1)
2 - filter(ROWNUM<=6)
4 - filter(ROWNUM<=6)
5 - filter(("H"."LOCK_USER" IS NOT NULL AND "H"."STATUS"='0'))

如果强制采用index_desc hint的话，则逻辑读在10左右。
但是不管对xxxx表怎么收集统计信息，柱状图信息都是没用，还是走全表扫描。
采用10053来查看，oracle cbo开始的计算也是正常的，但是由于order by，它recost order by。
但是很奇怪的是，这条sql只涉及到一张xxxx表格，但是却是:
Best so far: Table#: 0 cost: 14778.3637 card: 1331298.0000 bytes: 22632066
****** Recost for ORDER BY (using join row order) *******
***********************
Join order[1]: UDB_RANDOM_PASSPORT[H]#0
ORDER BY sort
First K Rows: switch to Amode plans
(newjo-stop-1) k:0, spcnt:0, perm:1, maxperm:80000

我们一般情况下都是Recost for ORDER BY (using index)
这次却碰到了using join row order。
索引也重新建过了，但是还是“外甥打灯笼---照旧(舅)"
想来想去，觉的只可能跟表格有关系，于是抱着"死马当活马医"的想法，把xxxx表重新remove一下，然后把索引再rebuild。

神奇的是，这样居然就好了，oracle cbo又采用Recost for order by(using index)了。