在数据库的江湖里有些东西是明面上的规则，比如SQL语法；而有些则是暗地里的潜规则，比如行标识符。Ru果你只停留在写写`SELECT *`的层面可Neng永远体会不到这些底层机制的魅力与痛楚。今天咱们不聊那些虚头巴脑的理论，直接扒开数据库的表皮，kankanROWID以及它背后的技术演进，到底藏着什么玄机。特别是当我们从Oracle转向国产数据库时这种“水土不服”的感觉，相信hen多老DBAdou懂。

说实话，刚接触Oracle的时候，我对ROWID是充满敬畏的。这玩意儿简直就是数据库里的GPS定位系统。在Oracle的体系里每一条记录dou有一个唯一的ROWID，它直接告诉你这条数据躺在哪个数据文件的哪个块、哪一行上。这种物理地址的映射方式，带来的直接好处就是——快。快得惊人。当你通过ROWID去访问数据时数据库根本不需要走索引树，直接拿着地址去磁盘拿数据，那种效率是其他方式无法比拟的。

但是物理地址有个致命的弱点：不稳定。就像你搬家了地址就变了一样。一旦你对表进行重建、或者发生了行迁移，ROWID就会发生变化。这意味着，你不Neng把它当作长期的业务主键来用。我之前就吃过这个亏，在一个数据同步项目里天真地以为ROWID是不变的，结果同步了一晚上，数据对不上号，查了半天才发现是表Zuo了空间整理，ROWID全变了。

这时候再kankanKES的实现，你会发现一种完全不同的思路。KES为了兼容Oracle，也搞了个ROWID，但它的本质是逻辑标识。它不是物理地址，而是一串基于事务ID生成的Base64编码。这玩意儿虽然kan起来像乱码，比如`AAAAAAAAADQCAAAAAAAAAAA`，但它是有序的、持久的。

这种设计上的取舍，其实hen有意思。Oracle选择了极致的性Neng，牺牲了稳定性；KES选择了逻辑上的可排序和可持久化，牺牲了一点点物理定位的速度。哪种geng好？没有标准答案。Ru果你追求的是毫秒级的响应，Oracle的物理ROWIDgeng香；但Ru果你需要表重建后标识符依然有效，或者需要按插入顺序排序，KES的逻辑实现可Nenggeng对你的胃口。

聊完ROWID，不得不提它的“难兄难弟”——OID。这套东西是从PostgreSQL继承过来的，但全局ID的生成是个性Neng瓶颈。所以KES把它改成了局部的。

这个改动解决了并发问题，但也带来了一个坑：牺牲了全局唯一性。geng糟糕的是OID还有个著名的“回卷”问题。当OID用完了它会从头开始，这会导致业务逻辑出现极大的混乱。我之前有个项目，就是因为开发同学贪图方便，直接拿OIDZuo业务主键，结果数据量一上来各种诡异的问题层出不穷，Zui后不得不重构代码。

所以现在的趋势是OID逐渐退居二线，主要在系统表里发挥作用，而业务表的行标识符大权，逐渐移交给了ROWID。这个演进过程，其实就是数据库从“学术理想”向“工程实用”转变的一个缩影。

Ru果你决定在KES里使用ROWID，那你得先Zuo好心理准备，因为它的参数配置有点“反直觉”。KES里有两个著名的参数：`default_with_rowid`和`default_with_oids`。这两个参数就像是一对冤家，是互斥的。

这里有个hen有趣的细节：ROWID的优先级geng高。Ru果你把两个参数dou开了建表时系统会默认使用ROWID，而忽略OID。这kan起来是个合理的设计，但在实际迁移中容易让人踩坑。我就遇到过这样的情况：明明全局开了`default_with_oids`，我想在建表时指定`with rowid`来特殊处理，结果报错告诉我“不Neng创建ROWID表，因为默认是OID”。这种时候，你只Neng乖乖地去改全局参数，或者在建表语句里仔细斟酌。

还有一个让人头大的参数是`enable_ci`。这个参数控制大小写敏感，但它只Neng在`initdb`的时候设置。一旦你的数据库集群建起来了这个参数就定型了想改？没门，重建吧。我之前有个项目就是因为初始化时手滑没关这个，导致后期应用对接时各种大小写不匹配的报错，那种绝望感，谁懂啊。

说了这么多理论，ROWID在实际项目中到底Neng干嘛？别小kan这个字段，关键时刻它Neng救命。

大表删除是每个DBA的噩梦。直接来一句`DELETE FROM huge_table WHERE status='inactive'`，可Neng会锁表锁到天荒地老，业务直接瘫痪。这时候，ROWID就是你的救星。

我们Ke以利用ROWID进行分批处理。因为ROWID是有索引的，通过ROWID定位数据的速度非常快。我们Ke以写一个存储过程，每次只删一万条，提交一次事务。这样虽然总耗时可Neng没变，但对业务的影响降到了Zui低，锁的粒度也变小了。我之前清理一个几千万行的日志表，就是用这个方法，跑了一晚上，第二天业务毫无感知，数据就清干净了。

在hen多并发geng新的场景，我们习惯加一个`version`字段来Zuo乐观锁。但其实Ru果你的并发要求不是极致的高，利用ROWID也Neng实现类似的效果。

逻辑是这样的：查询的时候把ROWID查出来geng新的时候带上ROWID作为条件。比如`UPDATE table SET score=100 WHERE user_id=1 AND rowid='...'`。Ru果geng新返回0行，说明在这期间数据被别人修改过了ROWID变了。应用层捕获到这个情况，就Ke以提示用户刷新数据。

这种写法省去了维护version字段的麻烦，代码逻辑也简洁不少。当然要注意ROWID在DELETE后可Neng被重用的问题，所以在极高并发下还是老老实实用version字段比较稳妥。但在一些低频geng新的配置表里这招简直太好用了。

从Oracle迁移到KES的时候，游标geng新是个重灾区。Oracle里写起来hen爽，直接`WHERE CURRENT OF cursor`就完事了。但在KES里为了保证兼容性和稳定性，官方推荐的Zuo法是把ROWID查出来然后用ROWID去geng新。

虽然代码行数多了点，kan起来也没那么“高级”，但这种方式逻辑清晰，而且避免了某些复杂场景下`CURRENT OF`失效的隐患。我在迁移存储过程的时候，基本上dou改成了这种模式，虽然麻烦点，但睡得踏实。

从技术演进的角度kan，早期数据库大家dou在追求标准化，SQL-92、SQL-99，恨不得天下大同。但后来发现，不现实。Oracle有Oracle的霸道，MySQL有MySQL的灵活，PostgreSQL有PostgreSQL的极客。用户一旦选型，就被生态绑死了。

国产数据库要突围，兼容性是必经之路。KES在ROWID和OID上的实践，其实就是一道平衡题。既要兼容Oracle的习惯，让迁移成本尽量低；又要保持自身的技术独立性，不Neng完全照搬Oracle的内核实现。比如KES支持ROWID作为数据类型，甚至Ke以比较大小，这既兼容了Oracle的用法，又利用了自身逻辑标识的特性。

当然这条路还hen长。参数体系的复杂度、文档的完善度、工具的易用性，dou还有hen大的提升空间。但不可否认的是我们Yi经kan到了从单纯模仿到自主创新的转变。未来Ru果Neng进一步简化这些繁琐的参数配置，提供geng清晰的迁移指南，相信会有geng多人愿意尝试。

Zui后说一句，技术这东西，没有银弹。ROWID也好，OID也罢，理解了背后的原理，你才Neng在实战中Zuo出正确的选择。别被表面功Neng迷惑，也别被复杂的参数吓倒。毕竟我们这些技术人员存在的意义，不就是解决这些麻烦事吗？希望国产数据库Neng越来越好，真正在关键领域顶上来这需要我们的支持，也需要geng多的反馈和包容。