原表如下:
NUM  NAME      ROWID 
1    aa   AAAM1CAAEAAAAGkAAA 
2    bb   AAAM1CAAEAAAAGkAAB 
3    cc   AAAM1CAAEAAAAGkAAC 
4    ee   AAAM1CAAEAAAAGkAAD 
5    ii   AAAM1CAAEAAAAGkAAE 
6    rr   AAAM1CAAEAAAAGkAAF 插入一行后,ROWID值变成如下:
7    pp   AAAM1CAAEAAAAGnAAA 再插入2行后,ROWID值又变成如下了:
8    nn   AAAM1CAAEAAAAGkAAG 
0    qq   AAAM1CAAEAAAAGkAAH 结果select后的排序为(其实0这一行,我是放在1前面插入的,为什么会跳到后面去?):
1    aa   AAAM1CAAEAAAAGkAAA 
2    bb   AAAM1CAAEAAAAGkAAB 
3    cc   AAAM1CAAEAAAAGkAAC 
4    ee   AAAM1CAAEAAAAGkAAD 
5    ii   AAAM1CAAEAAAAGkAAE 
6    rr   AAAM1CAAEAAAAGkAAF 
8    nn   AAAM1CAAEAAAAGkAAG 
0    qq   AAAM1CAAEAAAAGkAAH
7    pp   AAAM1CAAEAAAAGnAAA为什么地址会跳动?如果不安顺序,这种顺序很难看诶,SQLSERVER里面不是安顺序的么?

解决方案 »

  1.   

    rowid是由系统按自己的规则分配的,不能保证按记录插入的顺序递增
    如果要排序,用order by比较保险
      

  2.   

    lz执行下这个sql:
    select dbms_rowid.ROWID_RELATIVE_FNO(rowid) rfile#,
    dbms_rowid.ROWID_BLOCK_NUMBER(rowid) block#,
    dbms_rowid.ROWID_ROW_NUMBER(rowid) row#,表.*
    from 表;
      

  3.   


    rowid是物理地址,所以如果不是用append的方式插入的,很难保证后面的rowid一定大于前面的。
      

  4.   

    哦,APPEND方式怎么用的?能举个例子吗?
      

  5.   


    恩,结果如下:
    RFILE# BLOCK# ROW# NUM NAME 
    4      420     0    1   aa 
    4      420     1    2   bb 
    4      420     2    3   cc 
    4      420     3    4   ee 
    4      420     4    5   ii 
    4      420     5    6   rr 
    4      420     6    8   nn 
    4      420     7    0   qq 
    4      420     8    9   mm 
    4      423     0    7   pp 为什么块号直接从420跳到423了?还有第9行的ROW怎么没有了?
      

  6.   

    通过上面这个事实,你就知道了tom曾经说过的话:“对于堆表数据的插入,数据会被写到最适合的块,而不是以特定的顺序写入。”所以除非你用iot,否则不带条件的select是无序的。至于为什么(7,pp)这行数据不用420数据块,而用了423。我想也许是420满了,也许这就是“最适合的块”的内部算法决定的。我也不知道。 
      

  7.   

    不在一个数据块,multiblock read时自然不能保证顺序。但是如果不用iot,而先建索引,再插数据,查询时也不用INDEX_FFS,这时的select会不会按插入顺序显示呢?我觉得有可能。lz可以试试。
      

  8.   

    insert /*+append*/ into table1 …………
      

  9.   


    哦,很有道理,不过IOT是指什么(是指排序吗)?
      

  10.   


    APPEND旁边的符号也要吗?我试试