这个问题本质上是在问：**多个请求同时修改同一条数据，怎么避免并发覆盖？**

例如数据库：balance = 100，两个请求同时执行：

```Plain
A：余额 - 30
B：余额 - 50
```

比如 A 的伪代码是：

```Java
// 获取到 id 为 1 的余额
// SELECT balance FROM account WHERE id = 1;
// 然后代码中执行余额减30
balance = balance - 30

//...

// 又更新了余额为70
// UPDATE account SET balance = 70 WHERE id = 1;
```

B 同样读取 100，最终：

```Plain
A 减30 balance 变成了 70
B 减50 balance 变成了 50
```

但是 balance 最终正确的结果应该是 20。因此，我们需要避免这种并发修改的问题。

## 第一种方案：直接让数据库做原子更新

这是我最推荐面试先说的方案。

不要：

```SQL
SELECT balance ...
UPDATE balance ...
```

而是直接：

```SQL
UPDATE account
SET balance = balance - 30
WHERE id = 1
  AND balance >= 30;
```

因为：`balance = balance - 30` 是在数据库内部完成的。即使两个请求并发执行，数据库也会进行并发控制。比如还是最之前的例子，如果我们这样设计 SQL 语句，那最终就会让 100 先减 30 再减 50，最终的结果就是 20。

对于这种**简单的数值增减、计数器、库存扣减**场景，这是最优先考虑的方案。

## 第二种方案：悲观锁

为什么要叫悲观锁呢？主要就是因为这种加锁情况，我们会以一种更加悲观的态度来看待，会假设大部分情况都会并发冲突。所以在操作前就会直接上锁。

如果修改逻辑比较复杂，可以使用数据库行级锁或表级锁来实现（像数据库中的 select ... for update 就是典型的悲观锁）：

```SQL
SELECT balance
FROM account
WHERE id = 1
FOR UPDATE;

UPDATE account
SET balance = 70
WHERE id = 1;
```

在事务里面：

```SQL
BEGIN

SELECT ... FOR UPDATE

计算业务逻辑

UPDATE account ...

COMMIT
```

这样同一时间只有一个事务可以拿到这条记录的排他锁。例如：

```Plain
A 获取锁
↓
A 修改
↓
A 提交
↓
B 获取锁
↓
B 修改
```

适合：修改逻辑复杂，而且必须保证串行修改的场景。**总结就是并发冲突多，写多读少的场景。**

优点就是：保证强一致性，无需重试。缺点就是：并发高的时候锁竞争比较严重；加锁成本高，性能低，容易引发死锁。

## 第三种方案：乐观锁

这种方案就和上面的悲观锁完全相反，是以一种乐观的态度进行处理的，也就是假设并发冲突的场景大概率不会存在。所以他在一开始不加锁，而是获取版本号，等到更新的时候，再根据版本号去校验，看看数据是否被修改，如果已经被修改，那么这次更新失败，只能重试。

例如数据库字段 `version = 10`，先查询：

```SQL
SELECT balance, version
FROM account
WHERE id = 1;
```

得到：

```Plain
balance = 100
version = 10
```

更新：

```SQL
UPDATE account
SET balance = 70,
    version = 11
WHERE id = 1
  AND version = 10;
```

如果返回：

```Plain
affected_rows = 1
```

说明更新成功。

如果：

```Plain
affected_rows = 0
```

说明已经被其他请求修改了。然后需要重试。

这就是乐观锁。适合并发冲突少、读多写少的场景。除了 update 字段，很多时候我们也可以采用时间戳作为版本号。

优点就是：无锁性能高。缺点就是：冲突需要重试，写密集时性能反而差。

## 第四种方案：Redis 分布式锁

如果这个操作不是单机服务，而是具有多个服务实例：

```Plain
服务实例 A
服务实例 B
服务实例 C
```

这时候 JVM 的 synchronized 和 ReentrantLock 只能锁住当前实例，无法解决跨实例并发。

可以使用 Redis 分布式锁：

```SQL
SET lock:user:1 xxx NX EX 10
```

拿到锁，执行数据库更新，然后再释放锁。

> **注意：数据库字段并发更新，优先考虑数据库本身的原子更新、乐观锁、悲观锁，而不是一上来就 Redis 分布式锁。**

因为 Redis 锁会增加系统复杂度，而且还涉及：

* 锁过期
* 锁误删
* 业务执行时间超过 TTL
* Redis 故障
* 续期
* 等等一系列问题。。。

## 面试回答

面试官如果问：“并发操作数据库一个字段，怎么处理？”

你可以直接这么答：

> 如果只是库存、余额、点赞数、计数器这种简单字段更新，我优先使用数据库原子更新，比如 `UPDATE ... SET count = count + 1`，避免先查后改导致丢失更新。
> 
> 如果业务逻辑比较复杂，需要先读取数据再判断再修改，我会考虑悲观锁 `SELECT ... FOR UPDATE`（并发冲突多，写多读少的场景），或者乐观锁（并发冲突少、读多写少的场景）。
> 
> 如果是分布式环境下，需要保证某段跨数据库、跨服务的业务逻辑同一时间只有一个实例执行，再考虑 Redis 分布式锁。



但是 balance 最终正确的结果应该是 20。因此，我们需要避免这种并发修改的问题。

如何处理并发操作同一数据库字段？

数据库

后端

编程语言

并发更新同一条数据时，优先用数据库原子操作如`UPDATE balance=balance-30`避免覆盖；复杂逻辑可用悲观锁（`SELECT FOR UPDATE`）保证串行，或乐观锁（版本号校验）应对低冲突场景。分布式环境才考虑Redis锁，防止跨实例竞争，同时需注意锁过期与误删问题。

代码解释

Redis

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

如何处理并发操作同一数据库字段？-腾讯云开发者社区-腾讯云

如何处理并发操作同一数据库字段？

如何处理并发操作同一数据库字段？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐