作者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