Oracle中SELECT...FOR UPDATE实现分布式锁的底层逻辑是利用行级TX锁与事务绑定：仅当事务未提交时，其他会话对同一唯一索引行执行该语句会被阻塞或报ORA-00054；必须在显式事务中执行，锁对象需有唯一约束，且须设NOWAIT与CommandTimeout防死锁和连接耗尽。
Oracle 中用 SELECT ... FOR UPDATE 实现锁的底层逻辑
分布式锁在 .net + oracle 场景下，不能依赖 redis 或 zookeeper 这类外部组件时，select ... for update 是最直接、可控的方案。它的本质是利用 oracle 行级锁 + 事务隔离机制：只要事务未提交，其他会话对同一行执行 select ... for update 就会被阻塞或立即报错（取决于是否加 nowait）。
关键点在于：锁必须落在有唯一约束的行上（比如主键或唯一索引列），否则可能升级为表锁或锁住多行，导致误阻塞。
- 必须确保目标表存在唯一索引（如
lock_key字段上有UNIQUE约束） - 推荐显式加
FOR UPDATE NOWAIT，避免无限等待；捕获ORA-00054: resource busy错误作为“获取锁失败”的信号 - 不要用
INSERT ... ON DUPLICATE KEY UPDATE类似逻辑——Oracle 没有原生语法，模拟成本高且易竞态
.NET 中用 Oracle.ManagedDataAccess 执行带锁查询
使用官方驱动 Oracle.ManagedDataAccess（v21.x+）时，SELECT ... FOR UPDATE 必须在显式事务中执行，否则会抛出 ORA-01002: fetch out of sequence 或静默失效。
典型错误写法：connection.CreateCommand().ExecuteReader() 直接调用——没开事务，锁不生效。
- 必须用
connection.BeginTransaction()启动事务，再创建OracleCommand并设置Transaction属性 - 命令文本形如：
"SELECT 1 FROM lock_table WHERE lock_key = :key FOR UPDATE NOWAIT" - 执行后若抛出
OracleException且Number == 54，说明锁已被占用，应快速失败而非重试等待 - 成功获取锁后，业务逻辑必须在同一事务内完成；提交事务即释放锁，回滚也会释放
避免死锁和超时的经典陷阱
多个服务实例按不同顺序访问锁表行，或锁持有时间过长，极易引发死锁（ORA-00060）或连接池耗尽。Oracle 默认 DML 超时是无限的，但 .NET 的 OracleConnection 有 Connection Timeout（只管建连，不管锁等待）。
- 务必在连接字符串中设置
Connection Timeout=15，并在命令级别设CommandTimeout=10（单位秒），防止锁等待拖垮整个请求链路 - 所有锁操作必须遵循“固定顺序”：例如始终按
lock_key字典序加锁，禁止 A 先锁 “order_123” 再锁 “user_456”，而 B 反过来操作 - 禁止在持有数据库锁期间调用外部 HTTP 接口或长时间计算——锁粒度要小，业务逻辑尽量原子化
- 监控
v$session_blockers和v$locked_object视图，及时发现长事务占锁
为什么不用 DBMS_LOCK 包
DBMS_LOCK 是 Oracle 提供的 PL/SQL 锁管理包，表面看更“专业”，但它依赖 DBMS_LOCK.ALLOCATE_UNIQUE 创建锁句柄，且锁 ID 在实例间不共享（RAC 环境下不可靠），还要求用户有 EXECUTE 权限——这在多数生产环境被安全策略禁止。
相比 SELECT ... FOR UPDATE，它多一层抽象、调试困难、权限风险高，且无法通过 .NET 直接控制超时行为（DBMS_LOCK.REQUEST 的 timeout 参数单位是“十分之一秒”，精度反直觉）。
- 除非你已统一管控所有 Oracle 用户权限，并接受 RAC 下锁失效的风险，否则别碰
DBMS_LOCK -
DBMS_LOCK返回的LOCKED/NOT LOCKED状态不保证原子性，仍需配合事务验证 - 驱动层对
DBMS_LOCK的参数绑定支持不稳定，容易出现ORA-06502类型转换错误
NOWAIT 或忘了设 CommandTimeout，问题就会在流量高峰时集中爆发。 
