作者FireLake (XXX)
看板Database
標題Re: [SQL ] ROWID
時間Sun Jul 3 04:10:55 2011
※ 引述《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)
1F：推 LPH66:說起來其實PK(甚至是index key)做的就是這個對照表 07/03 04:20
2F：推 LPH66:而且它會用些技巧讓存取少量資料時不致於要掃整張表 07/03 04:24
3F：推 LPH66:不過大量資料時的慢也正是相對用ROWID多了這個查表的動作 07/03 04:29
4F：推 LPH66:所以如果資料變動率不高但查詢的量非常多的話不妨一試 07/03 04:34
5F：推 bohei:謝謝兩位大大 又上了一課! 07/03 10:37
6F：推 bobju:這ROWID看來對oracle有依存性。若程式當中大量引用ROWID， 07/03 11:49
7F：→ bobju:日後系統要從oracle移到mysql, 那麼程式豈非得跟著改改改？ 07/03 12:17
8F：→ FireLake:基本上只要用非標準SQL語法 換到別的資料庫時 都要改程式 07/03 13:04
9F：→ FireLake:如MSSQL的isnull() = Oracle的nvl() = DB2的coalesce()等 07/03 13:13