一级加X锁修改直到事务结束 → 防止丢失修改”描述的是数据库并发控制中两阶段封锁协议2PL下的一级封锁协议也称基本封锁协议其核心要点如下✅一级封锁协议定义事务在修改数据即执行WRITE(X)操作前必须对数据项 X 加排他锁Exclusive Lock, X锁该 X 锁必须持续到事务结束COMMIT 或 ROLLBACK即不能提前释放。✅目的与效果保证写-写冲突被串行化从而防止丢失修改Lost Update。例如T1 和 T2 同时读取同一数据项后各自修改并写回若无 X 锁保护T2 的写入可能覆盖 T1 的结果 → 丢失修改而一级封锁协议强制 T2 必须等待 T1 释放 X 锁后才能修改实现顺序执行。⚠️ 注意一级封锁协议不加锁读操作READ因此无法防止不可重复读和幻读它仅解决“丢失修改”是三级封锁协议中最弱的一级它满足**两阶段封锁增长段→收缩段**的基本要求X锁持至事务结束即严格2PL的一种形式。典型流程示例 T1: LOCK-X(A) → READ(A) → MODIFY(A) → WRITE(A) → UNLOCK(A) → COMMIT T2: LOCK-X(A) → ... 必须等待T1释放锁一级封锁协议仅要求对修改WRITE操作加X锁并持至事务结束但对读READ操作不加任何锁即不加S锁或X锁。这直接导致其无法防止不可重复读Non-repeatable Read原因如下不可重复读的定义同一事务中两次读取同一数据项得到不同值。通常由其他事务在两次读之间修改并提交了该数据项所致。一级协议的缺陷分析结合实例假设事务 T1 执行两次读取 A事务 T2 修改 A 并提交T1: READ(A) → 读到 A100 T2: LOCK-X(A) → WRITE(A200) → COMMIT → UNLOCK-X(A) T1: READ(A) → 读到 A200与第一次不同T1 在两次READ(A)前未加S锁一级协议不要求因此不阻塞 T2 的 X 锁请求T2 成功获取 X 锁、修改并提交释放锁后 T1 第二次读取时看到新值由于 T1 对 A无锁保护其读操作是“脏读”若T2未提交则属脏读或“不可重复读”T2已提交而一级协议既不防未提交读无S锁也不防已提交修改无读锁持续保护。✅ 结论读操作不加锁 → 无法阻止其他事务并发修改并提交 → 同一事务内多次读取结果可能不一致 → 不可重复读发生。要防止不可重复读需升级到二级封锁协议要求读操作加S锁且S锁至少保持到读操作结束部分实现持至事务结束。
