NONE 5705
LOGOUT_DATE DATE Y 62654 101280 .000015961 1 YES NONE 45052
LOGIN_DATE DATE Y 94539 0 .000010578 1 YES NONE 56591
MAC VARCHAR2(25) Y 6 365396 .166666667 1 YES NONE 1542
IP VARCHAR2(20) Y 33242 83919 .000128916 254 YES HEIGHT BALANCED 47030
STAFF_CODE VARCHAR2(20) Y 16950 0 .000199561 254 YES HEIGHT BALANCED 5705
SESSION_ID VARCHAR2(100) Y 405087 91292 2.4686E-06 1 YES NONE 46190
LOG_ID NUMBER(12,0) N 496712 0 2.0132E-06 1 YES NONE 5705
都是这个order by desc使CBO倾向于走INDEX FULL SCAN DESCENDING(如果你有相关的知识，应该知道，index_fs会读取所有的索引块，当然这个读取时有序的,因为我们有order by desc，所以是从索引叶块的最右端，降序的来读)然后再回表。
很明显，走错了索引，正常的应该走IDX_SEC_LOGIN_LOG1_201208,1号的数据变化比较大，走错了索引. www.2cto.com
看正确的执行计划：
[html]
SQL_ID 0a3zj3m5h72rb
--------------------
select M.LOG_ID,M.STATE,M.SESSION_ID,M.IP,M.LOGOUT_DATE,M.LOGIN_DATE,M.STAFF_COD
as MROWID___ from SEC_LOGIN_LOG_201208 M where M.SESSION_ID = :1 order by M.L
Plan hash value: 1455286942
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | |
| 1 | SORT ORDER BY | | 1 | 108
| 2 | TABLE ACCESS BY INDEX ROWID| SEC_LOGIN_LOG_201208 | 1 | 108
| 3 | INDEX RANGE SCAN | IDX_SEC_LOGIN_LOG1_201208 | 1 |
--------------------------------------------------------------------------------
小小sql,其实平时即使遇到大的sql，复杂的，多表连接的，执行计划几百行的，都一样，收集相关的对象的信息是必不可少的。
作者 Coast_lichao