rowid更新比主键快是因为它直接定位物理地址，跳过索引扫描与回表；java中需用getrowid()获取、setrowid()绑定，避免getstring/setstring导致失效。
直接用 rowid 做 where 条件，比任何索引字段都快——但必须确保你拿到的是当前有效的 rowid，且不跨事务、不跨表移动。
为什么 Java 里用 ROWID 更新比用主键快
Oracle 的 ROWID 是物理地址的 Base64 编码（如 AAAR3qAAEAAAACHAAC），数据库引擎能直接跳转到对应数据块和行偏移，绕过所有索引扫描和谓词计算。而主键更新要先走索引定位、再回表，多一次 B-Tree 查找开销。
实测对比（千万级表）：
– 按主键 WHERE id = ?：平均 8–12ms
– 按 ROWID WHERE rowid = ?：稳定在 0.3–0.8ms
差距主要来自 I/O 跳转层级和 latch 竞争降低。
-
ROWID查询是 Oracle 最底层的访问路径，JDBC 驱动无需额外转换，直接透传 - 注意：它只对堆表（heap table）有效；IOT 表用的是逻辑
ROWID，性能增益有限 - 不能用于分区表的全局唯一定位——分区迁移后
ROWID可能失效
Java 中正确获取并使用 ROWID 的三步
关键不是“怎么写 SQL”，而是“怎么拿、怎么传、怎么防失效”：
- 查询时必须显式 SELECT
ROWID，不能依赖别名或 *：SELECT rowid, name, salary FROM emp WHERE deptno = ? - JDBC 获取要用
ResultSet.getRowId()，不是getString("rowid")：
前者返回oracle.sql.ROWID对象，后者会丢失二进制语义，导致绑定失败 - 更新时用
PreparedStatement.setRowId()绑定，不是setString()：
否则 Oracle 服务端会当作普通字符串解析，触发隐式类型转换，失去物理定位能力
错误示例：ps.setString(1, rs.getString("rowid")); → 触发 full table scan 或报 ORA-01410: invalid ROWID
哪些操作会让已获取的 ROWID 失效
ROWID 不是永久身份证，它是“快照地址”。以下任一操作后，旧 ROWID 就作废：
-
ALTER TABLE ... MOVE或SHRINK SPACE—— 行物理位置重排 -
TRUNCATE TABLE—— 全表重置，ROWID全部刷新 - 行迁移（row migration）：当 update 导致单行超出块容量，Oracle 搬到新块并留指针，原
ROWID指向指针而非真实数据 - 表启用压缩（
COMPRESS FOR OLTP）后插入/更新，可能触发块内重组织
所以：不要缓存 ROWID 超过单次事务生命周期；不要在异步任务里复用之前查出的 ROWID；批量更新前务必重新 SELECT + ROWID。
金仓（KingbaseES）等兼容库的特别注意点
国产库模拟 ROWID 机制时，底层其实是 OID 字段映射（如 AAAAAAAAADQCAAAAAAAAAAA），不是物理地址：
- 开启需显式配置：
SET default_with_rowid = true;，否则建表不带该伪列 - OID 可被重用（delete 后 insert 新行可能分配相同 OID），
ROWID不具备 Oracle 级别的唯一性保证 - Java 侧仍可用
getRowId()，但驱动内部做了 OID → 字符串转换，性能略低于 Oracle 原生ROWID - 迁移 Oracle 应用时，检查是否用了
DBMS_ROWID包——金仓不支持该包，解析逻辑需重写
最易忽略的点：Oracle 的 ROWID 在同一事务内绝对稳定；而某些兼容库在 autocommit=false 下，两次 SELECT 可能拿到不同 ROWID（因 OID 分配时机差异），务必验证行为一致性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
