本文由 简悦 SimpRead 转码， 原文地址 blog.csdn.net
在高并发场景下，MySQL 处理并发修改同一行数据的安全方法主要有以下几种：
-
悲观锁（Pessimistic Locking）：
- 使用
SELECT ... FOR UPDATE语句，在事务中锁定需要修改的行。这样其他事务在该行被解锁之前无法对其进行修改。 ```sql START TRANSACTION; SELECT * FROM table WHERE id = ? FOR UPDATE; -
-
根据查询结果进行更新操作 UPDATE table SET column = value WHERE id = ?; COMMIT;
CREATE TABLE my_table ( id INT PRIMARY KEY, data VARCHAR(50), version INT DEFAULT 0 );
-
- 使用
-
乐观锁（Optimistic Locking）：
-
乐观锁不阻止并发访问，而是在更新时检查自上次读取以来数据是否已被修改。实现上通常通过一个额外的版本号字段或时间戳字段来完成。
-
在 MySQL 中，可以通过在表中增加一个 version 字段，并在更新时判断 version 值是否未变来实现乐观锁。
START TRANSACTION; SELECT stock FROM products WHERE product_id = ? FOR UPDATE; -- 检查并计算新的库存值 UPDATE products SET stock = new_stock WHERE product_id = ?; COMMIT;
-- 更新时使用版本号作为条件 UPDATE my_table SET data = 'new_value', version = version + 1 WHERE id = ? AND version = ?;
UPDATE products SET stock = new_stock, version = version + 1 WHERE product_id = ? AND version = current_version; -
-
事务隔离级别调整：
- 调整数据库事务的隔离级别，例如将隔离级别设置为
REPEATABLE READ（InnoDB 默认级别），可以防止脏读和不可重复读，但这并不能完全避免幻读问题，对于解决并发更新问题仍需配合上述锁策略。
- 调整数据库事务的隔离级别，例如将隔离级别设置为
-
队列处理：
- 对于极高的并发需求，可以引入消息队列系统，让所有修改请求先进入队列，然后由后台服务按照队列顺序逐个处理，从而避免直接的竞争冲突。
-
应用层控制：
- 在应用程序层面采用分布式锁、Redis 等中间件实现锁机制，或者设计更复杂的业务逻辑，如使用 “预扣库存” 的原子操作减少对数据库行级锁的依赖。
结合实际应用场景和数据库特性选择合适的并发控制策略，才能既保证数据的一致性，又兼顾系统的高性能。
举例子：
熊二：光头强，咱们现在这小卖部的生意火爆得不行，有时候同时好多人下单买同一件商品，你要是用 MySQL 更新库存的时候，万一被别人插队给改了咋整？
光头强：嘿，那不是乱套了吗？我可不想有人空手套白狼把咱的商品都给 “抢” 光了！
熊二：没错！为了避免这种情况，我给你支几招。首先，可以试试悲观锁，就像超市收银台排队结账一样。
光头强：怎么个排法？
熊二：就是在你准备修改库存前，先用SELECT ... FOR UPDATE跟数据库说：“嘿，我要改这个商品的库存，你们其他人先别动，等我改完了再轮到你们。”
START TRANSACTION;
SELECT stock FROM products WHERE product_id = ? FOR UPDATE;
-- 检查并计算新的库存值
UPDATE products SET stock = new_stock WHERE product_id = ?;
COMMIT;
光头强：哦，懂了，就是先占坑再操作。那还有别的招吗？
熊二：当然有，还有一种叫乐观锁，这就像是每件商品都有个 “标签”，每次改库存之前都要看看这个标签有没有变。
光头强：啥标签？
熊二：在数据库里加一个版本号字段，比如version。每次修改时，不仅要更新库存，还要把版本号 + 1。
UPDATE products
SET stock = new_stock, version = version + 1
WHERE product_id = ? AND version = current_version;
如果更新失败（受影响行数为 0），那就说明期间有人捷足先登，这时候你就重新获取最新数据，再尝试更新。
光头强：哈哈，这招更像玩捉迷藏，谁动作快谁就赢！
熊二：对啊，各有各的好处，具体选哪一招，就得看咱小卖部的实际需求和性能瓶颈了！