Examine these statements issued from Session 1 which execute successfully:
Session 1>
SET autocommit=1;
SELECT * FROM band FOR UPDATE;
Now, examine these statements issued from Session 2 which execute successfully:
Session 2>
BEGIN;
UPDATE band SET song=CONCAT("Here Comes the ", song) WHERE song LIKE '%Sun';
Which two are true?
A)Session 1 takes a shared lock on all the rows in the band table.
B)Session 1 must commit before the update in Session 2 can complete.
C)Session 1 does not block Session 2.
D)Statements in Session 2 are committed.
E)Session 2 takes an exclusive lock on all the rows in the band table.
F)Session 2 does not start a transaction.
题目翻译
检查以下从会话1发出的成功执行的语句:
Session 1>
SET autocommit=1;
SELECT * FROM band FOR UPDATE;
检查以下从会话2发出的成功执行的语句:
Session 2>
BEGIN;
UPDATE band SET song=CONCAT("Here Comes the ", song) WHERE song LIKE '%Sun';
以下哪两项是正确的?(选择两项)
知识点解析
📌 核心考点:事务与锁机制(考试大纲 Section 7.2)
🔍 技术详解:
-
autocommit=1*:自动提交模式。每个单条SQL语句作为一个独立事务,执行后立即提交。 -
SELECT ... FOR UPDATE:对查询行加 排他锁 (X锁),阻止其他事务修改或加锁。 -
BEGIN:显式开启事务,暂关autocommit,后续语句需显式COMMIT。
⚠️ 易错点:
- 锁释放时机:
SELECT ... FOR UPDATE在autocommit=1时,语句结束 立即提交并释放锁。 - 事务生命周期:Session 2 的
BEGIN开启事务,但 未提交(无COMMIT),锁持续持有。
图示

答案分析
✅ 正确选项:
B) Session 1必须提交,Session 2的更新才能完成。
-
依据:
- Session 1 的
SELECT ... FOR UPDATE因autocommit=1立刻释放锁。 - 若 Session 1 未提交(如
autocommit=0),Session 2 会阻塞等待锁释放。
📘 官方文档 15.7.1:FOR UPDATE 加锁行为取决于事务提交时机。
- Session 1 的
C) Session 1 不会阻塞 Session 2。
- 依据:
- Session 1 执行完毕后锁立即释放,Session 2 的 UPDATE 无需等待。
- 图示中 Session 2 的 UPDATE 直接执行成功。
❌ 错误选项排除逻辑:
A) Session 1对表加共享锁
- ⚠️ FOR UPDATE 是 排他锁 (X锁),非共享锁(S锁)。
D) Session 2的语句已提交
- ⚠️
BEGIN后需显式COMMIT,Session 2 未提交(事务仍活跃)。
E) Session 2对全表加排他锁
- ⚠️ UPDATE 仅对 匹配
song LIKE '%Sun'的行 加排他锁(若字段无索引,可能加全表扫描的临键锁,但非“所有行”)。
F) Session 2 未开启事务
- ⚠️
BEGIN显式开启事务,暂关autocommit。
锁机制总结
| 锁类型 | 持有方 | 行为 | 释放时机 |
|---|---|---|---|
| 排他锁 (X锁) | Session 1 | 阻塞其他事务的写锁/排他锁 | autocommit=1 → 立即 |
| 排他锁 (X锁) | Session 2 | 锁定匹配行,允许读 | 显式 COMMIT 后释放 |





