校招数据库高频题：用一次并发转账讲透死锁、重试与资金不变量

关注 「软件测试就业联盟」公众号，陪你走好校招求职的每一步

面试官写下两条 SQL：先扣 A，再给 B 加钱。每条 UPDATE 单独执行都没问题，为什么 A 转 B 与 B 转 A 同时发生时会死锁？

如果只回答“数据库锁冲突”，还不够。高分答案要把两个事务的时间线画出来，并继续说明怎样修、怎样重试、怎样验证资金没有被重复移动。

死锁发生在事务之间
事务 T1 先锁账户 A，准备再锁 B；事务 T2 先锁 B，准备再锁 A。T1 等 T2 释放 B，T2 又等 T1 释放 A，等待图形成环。数据库通常会检测这个环，选择回滚其中一个事务，让另一个继续。

所以日志里可能看到的不是永久卡死，而是一个事务收到 deadlock detected 或 deadlock victim。应用若把它当普通 500 返回，用户就会觉得转账随机失败。

最直接的修复：统一锁顺序
无论资金从谁转给谁，都按 account_id 从小到大获取锁。A 转 B 与 B 转 A 会争抢同一个第一把锁，其中一个等待，但不会形成环。

BEGIN;

SELECT account_id, balance
FROM account
WHERE account_id IN (:from_id, :to_id)
ORDER BY account_id
FOR UPDATE;

UPDATE account
SET balance = balance - :amount
WHERE account_id = :from_id
AND balance >= :amount;

UPDATE account
SET balance = balance + :amount
WHERE account_id = :to_id;

INSERT INTO transfer_ledger(request_id, from_id, to_id, amount)
VALUES (:request_id, :from_id, :to_id, :amount);

COMMIT;
应用必须检查扣款 UPDATE 是否影响一行，否则余额不足时不能继续入账。transfer_ledger 的 request_id 应唯一，防止客户端或死锁重试重复转账。

为什么“捕获异常后重试”也可能出错
若应用每次重试都生成新的 request_id，第一次事务其实已提交但响应丢失时，第二次会再次转账。重试必须复用同一业务键，并只针对明确可重试错误，例如数据库报告的死锁或短暂锁等待超时。

退避也要有限，避免高冲突时所有线程立即重试形成新一轮碰撞。超过次数后返回可查询状态，让用户按 request_id 查最终结果。

import random
import time

def transfer_with_retry(service, command, max_attempts=3):
for attempt in range(max_attempts):
try:
return service.transfer(command) # command.request_id 始终不变
except service.DeadlockError:
if attempt == max_attempts - 1:
raise
time.sleep(0.02 * (2 ** attempt) + random.random() * 0.01)
自动化测试要主动制造等待环
普通并发压测不一定稳定复现。测试可以用 Barrier 控制两个事务：T1 锁 A 后暂停，T2 锁 B 后暂停，再让两边同时请求第二把锁。这样每次都能命中目标时序。

修复统一顺序后，继续跑相同实验，预期不再形成等待环；可能有一个事务短暂等待，但两者最终只有成功或明确余额不足。

最后用业务不变量收口
无论发生死锁、回滚还是重试，两个账户总余额保持不变；每个 request_id 最多一条成功流水；流水金额与账户差额一致；任何中间失败都不能出现只扣不加。

面试时可以按这个顺序回答：画等待环，说明数据库会回滚一个事务；用固定资源顺序预防；缩短锁持有时间；仅对可重试错误有限重试；用幂等键与余额对账保护终态。

如果你正在准备测试开发校招，这类题不要只背“死锁四条件”。通过 Python 全栈开发与自动化测试项目，亲手控制两个事务的交错并查询锁等待，你会真正理解并发测试为什么比单接口断言更难。

两条 UPDATE 的正确性，只属于各自的单线程世界；转账是否正确，要在事务交错、失败回滚和重试之后看最终资金账。

想及时获取2027届秋招第一手招聘消息、岗位汇总和内推信息，可以扫码加入秋招交流群。

关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。