Re: [SQL ] ROWID

[FireLake (XXX)]

※ 引述《bohei (run and fall)》之銘言：
: 不知道有沒有人知道這個東西QQ
: 每一ROW一定會有一個ROWID
: 我在網路上搜尋到的資料是ROWID會隨著TABLE改變而改變
: 如果有一個查詢、新增的程式
: 他利用ROWID去做搜尋的動作
: 在TABLE修改後也馬上更新PK跟ROWID之間的關係
: 他用ROWID當搜尋條件而不用PK
: 目的只是為了搜尋速度嗎?
: 用了ROWID當條件做搜尋
: 在資料量很大很大的時候
: 速度會遠比用PK當條件還快嗎?
: 還麻煩各位高手解答!

  ROWID會比PK快很多，尤其是資料量大的時候。以Oracle為例，光從ROWID
  就可以這個row是屬於那一個object, 位置在那一個datafile, 那一個block,
  和這個block的第幾row。

  但ROWID照你說的很有可能會隨著Table改變而改變，如果要在每一次Table修改
  後去記錄PK和ROWID的關係，即使不考量記錄的量大不大，這每一次的記錄過程
  等於是一次的 table scan，資料量大的時候可以跑很久。除非你在一個大的
  table中只有少量的row要記錄，或是table被更新的機會很小，且更新後有一段
  時間容許做 table scan，不然這不是一個很好的方法。

  補充一點: 當一個row被更新時，他的ROWID可能不會立刻更新，如果這個block在
            buffer pool 待一陣子，ROWID會等到後來被寫回 disk 時才被更新。
            所以更新一個row後立刻記錄ROWID有可能會記錄到舊的。

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 71.142.84.182
※ 編輯: FireLake        來自: 71.142.84.182        (07/03 04:21)
推 LPH66:說起來其實PK(甚至是index key)做的就是這個對照表
推 LPH66:而且它會用些技巧讓存取少量資料時不致於要掃整張表
推 LPH66:不過大量資料時的慢也正是相對用ROWID多了這個查表的動作
推 LPH66:所以如果資料變動率不高但查詢的量非常多的話不妨一試
推 bohei:謝謝兩位大大  又上了一課!
推 bobju:這ROWID看來對oracle有依存性。若程式當中大量引用ROWID，
→ bobju:日後系統要從oracle移到mysql, 那麼程式豈非得跟著改改改？
→ FireLake:基本上只要用非標準SQL語法 換到別的資料庫時 都要改程式
→ FireLake:如MSSQL的isnull() = Oracle的nvl() = DB2的coalesce()等