在實現位圖索引的時候，出現了一些問題，引發出對rowid的一些思考。
位圖索引的目的就是對於重複值較多的字段，如果通過B樹索引，可能要不斷的進行比較操作，而使用位圖索引，則可以通過按位操作直接定位到滿足條件的記錄上，這樣位圖索引對於每個關鍵字的值都應該有一個位圖，通過按位操作，找到記錄的rowid，然後通過rowid就可以直接定位到對應的記錄。
但是在達夢數據庫實現的時候，rowid並不是和記錄的物理位置相關聯的，而只是系統中的一個唯一值而已，這樣如果使用rowid的話，則找到rowid之後還需要一次聚簇索引查找操作，效率上就大打折扣了。
鑑於此，查看了一下ORACLE的rowid，ORACLE的rowid是直接和記錄的物理位置相關聯的，其組成爲：data_object_id#+rfile#+block#+row#組成，佔用10個bytes的空間， 32bit的 data_object_id#,10 bit 的 rfile#,22bit 的 block#,16 bit 的 row#. 這樣ORACLE在實現位圖索引的時候，可以很容易的通過rowid定位到記錄的物理位置。
達夢在實現位圖索引的時候，也考慮考慮修改rowid，將其改爲具體的物理位置，這樣一來帶來了另外一個問題，達夢創建表的時候會默認的建立聚簇索引，聚簇索引的葉子節點存儲了實際的記錄，這樣在對錶進行一些更新、刪除、插入操作的時候，記錄的物理位置可能發生變化，那麼位圖索引中響應的物理位置的值也需要跟隨着變化。
試驗了一下ORACLE的rowid，在對錶進行更新、刪除、插入操作的時候，記錄的rowid並不會發生變化，因此可以反推，ORACLE是不是沒有建立聚簇索引，而是將記錄分開存放的？這樣在插入、更新、刪除的時候，其物理位置並沒有發生改變？這樣來實現應該也是有其一定的道理的，聚簇的概念就是將相關的記錄儘可能的在物理上連續存放，這樣在讀取的時候可以減少很多的IO操作，而將記錄在物理上連續存放也是需要付出一定的代價的，即記錄可能在做更新操作的時候位置被挪動，從而帶來一定的開銷，因此用戶應該根據自己的需要在確實需要聚簇的時候來使用聚簇存儲。
但是達夢數據庫則默認的就創建了聚簇索引，這從一定程度上加快了記錄的存取速度，但是不可避免的也帶來了一部分的額外開銷。
不知有沒有高手來解答一下ORACLE的rowid在聚簇的時候到底是如何處理的？是否也可能發生變化？