在 oracle 19c 中，select ... for update 能可靠锁定满足 where 条件的行（需走索引），但必须在显式事务中使用，锁持续至 commit 或 rollback；裸执行、自动提交或未走索引会导致全表锁、阻塞或报错，应配合 nowait/wait n/skip locked 及 of 子句精准控制。
直接结论：在 Oracle 19c 中，SELECT ... FOR UPDATE 能可靠锁定满足 WHERE 条件的行（前提是走索引），但必须在事务内使用，且锁会持续到 COMMIT 或 ROLLBACK；裸执行或未提交事务会导致其他会话阻塞或报错。
FOR UPDATE 必须配合事务显式控制
Oracle 不会在自动提交模式下维持行锁。即使语句执行成功，若未开启事务或未显式 COMMIT/ROLLBACK，锁不会释放，后续操作极易卡死。
- 必须先执行
SET AUTOCOMMIT OFF（SQL*Plus/SQLcl）或在应用中显式开启事务（如 JDBC 的connection.setAutoCommit(false)） - 执行
SELECT * FROM orders WHERE order_id = 123 FOR UPDATE后，该行即被当前会话独占锁定 - 不调用
COMMIT或ROLLBACK，锁一直存在——哪怕客户端断开，Oracle 也会保留锁直到回滚超时（默认 60 秒）或 DBA 干预
WHERE 条件没走索引？可能锁整张表
锁粒度完全依赖执行计划。如果 WHERE 条件无法命中索引（例如对字段做函数操作、隐式类型转换、或字段无索引），Oracle 会退化为扫描全表并锁定所有访问过的行——在高并发场景下等同于“伪表锁”。
- 错误示例：
SELECT * FROM users WHERE UPPER(name) = 'ALICE' FOR UPDATE→ 函数导致索引失效，可能锁全表 - 正确做法：确保条件列有索引，且写法干净，例如
WHERE user_id = 1001（user_id是主键或有索引） - 验证方式：执行
EXPLAIN PLAN FOR ...后查PLAN_TABLE，确认ACCESS_PREDICATES非空且OPERATION含INDEX
避免无限等待：用 WAIT、NOWAIT 或 SKIP LOCKED
默认 FOR UPDATE 会无限期挂起，生产环境必须加超时控制。Oracle 19c 完全支持这三类行为，语义与 MySQL 兼容但语法略有差异。
-
FOR UPDATE NOWAIT：立即失败，报错ORA-00054: resource busy and acquire with NOWAIT specified -
FOR UPDATE WAIT 3：最多等 3 秒，超时抛ORA-30006: resource busy; acquire with WAIT timeout expired -
FOR UPDATE SKIP LOCKED：跳过已被锁的行，只返回未被锁的记录——适合队列消费类场景（如多 worker 处理任务表）
OF 子句不是可有可无，而是影响多表锁范围
当 SELECT 关联多个表（JOIN），且只打算更新其中一张表的字段时，OF 能精准缩小锁范围，避免误锁无关表的行。
- 不加
OF：SELECT a.id, b.status FROM orders a JOIN order_items b ON a.id = b.order_id WHERE a.id = 100 FOR UPDATE→orders和order_items中匹配行全被锁 - 加
OF a.id：... FOR UPDATE OF a.id→ 只锁orders表中该行，order_items行不锁（除非另有 DML 显式触发） - 注意：
OF后必须是 SELECT 列表中明确出现的列，且属于某张基表，不能是表达式或别名
真正容易被忽略的是锁的“可见性边界”：FOR UPDATE 锁的是当前读（current read）结果，不是快照；但其他会话的普通 SELECT 仍走多版本一致性读（MVCC），完全不受影响——只有同样带 FOR UPDATE 或执行 UPDATE/DELETE 时才会触发阻塞。这点和 MySQL InnoDB 的行为一致，但初学者常误以为“锁住=别人查不到”。
