rowid是oracle中最快的物理定位方式，但仅适用于堆表且不跨数据库兼容；可靠做法是使用唯一键（如id、email）配合索引查询，避免依赖rowid的稳定性缺陷。
ROWID 不是万能的，但它是最快的物理定位方式
ROWID 是 Oracle 数据库中每行数据在物理存储层面的唯一地址，查它比走索引快一个数量级。但它只在 Oracle 里原生存在，MySQL、PostgreSQL、SQL Server 都没有这个概念——别在其他数据库里搜 ROWID，会白忙。
常见错误现象：在非 Oracle 环境下写 SELECT ROWID, name FROM users，报错 Unknown column 'ROWID' in 'field list'；或者误以为 ROWID 跨事务、跨备份、跨导出导入仍稳定——其实它可能随表移动、分区重组、ALTER TABLE ... MOVE 等操作失效。
-
ROWID只适用于 Oracle，且仅对堆表（heap table）有效；索引组织表（IOT）的ROWID行为不同 - 用
ROWID定位后做UPDATE或DELETE，必须确保该行未被其他事务修改或删除，否则可能报ORA-01410: invalid ROWID - 不要把
ROWID存进业务字段或日志长期使用——它不是逻辑主键，不具语义稳定性
用唯一键（UK）或主键（PK）才是跨数据库的安全选择
如果你要“快速定位某一行”，真正可靠的方式是依赖已建好的唯一约束字段，比如 id、order_no、email。这些字段有索引支撑，查询计划通常是 INDEX UNIQUE SCAN，响应稳定，且不绑定数据库类型。
使用场景：后台管理查单、API 根据 ID 返回详情、定时任务按批次处理记录——所有这些，只要 WHERE 条件命中唯一索引，性能就接近最优。
- 确认字段确实有唯一约束：查
USER_CONSTRAINTS（Oracle）或INFORMATION_SCHEMA.KEY_COLUMN_USAGE（MySQL/PG） - 避免用
LIKE '%xxx'或函数包装唯一字段（如WHERE UPPER(email) = 'A@B.COM'），会导致索引失效，退化成全表扫描 - 复合唯一键（如
(tenant_id, ext_id)）必须所有列同时出现在 WHERE 中才能走索引，缺一不可
没有唯一键时，怎么临时准确定位某行？
有些老系统或日志表压根没主键，又急需定位某条“看起来一样”的重复数据。这时候不能靠猜，得构造临时唯一性。
常见错误现象：用 SELECT * FROM logs WHERE level = 'ERROR' AND msg LIKE '%timeout%' 查出 12 行，想删第 5 行，结果写 DELETE ... LIMIT 1 OFFSET 4 —— MySQL 的 LIMIT 在无 ORDER BY 时行为不确定，PostgreSQL 甚至不支持带 OFFSET 的无序 DELETE。
- 先加
ORDER BY明确顺序，例如ORDER BY id, created_at, ctid（PostgreSQL 用ctid，MySQL 8.0+ 可用隐藏列_rowid，但需开启innodb_row_locks） - 用子查询或 CTE 先锁定目标行：比如 PostgreSQL 写
WITH target AS (SELECT ctid FROM logs WHERE ... ORDER BY created_at LIMIT 1 OFFSET 4) DELETE FROM logs WHERE ctid IN (SELECT ctid FROM target) - Oracle 可用
ROWNUM但注意它在WHERE中不能直接写ROWNUM = 5，必须嵌套：SELECT * FROM (SELECT a.*, ROWNUM rn FROM (SELECT * FROM t WHERE ...) a) WHERE rn = 5
为什么别用 SELECT * + 应用层遍历找特定行
有人习惯先 SELECT * 拿回几千行，在代码里用 for 循环匹配字段值。这在小表上看似省事，实际埋了三个坑：网络传输放大、应用内存压力、无法利用数据库执行计划优化。
性能影响明显：10 万行 × 平均 200 字节 = 20MB 结果集，哪怕只取其中 1 行，也得全传、全解码、全遍历。而一条带索引条件的 SELECT ... WHERE id = ?，数据库通常只读几页磁盘，毫秒级返回。
- 如果业务逻辑必须多条件组合筛选（比如“状态=待发且创建时间在最近2小时且金额>100”），优先在数据库加联合索引，而不是扔给应用层筛
- ORM 如 MyBatis、Hibernate 默认不启用延迟加载时，
SELECT *可能触发 N+1 查询或冗余字段反序列化，进一步拖慢定位速度 - 某些字段含大文本（
CLOB/TEXT），即使你不需要，SELECT *也会强制加载，IO 和 GC 开销陡增
最常被忽略的一点：ROWID 和唯一键都不是“定位行”的终点，而是手段。真正的复杂点在于——你要定位的那一行，是否在查询发起瞬间还存在、是否已被锁住、是否属于当前事务可见的版本。这些，没法靠语法绕过去。
