mysql并发情况下如何保证数据正确_mysql一致性处理方法_网络技术

应使用SELECT ... FOR UPDATE加行级写锁防止并发更新丢失，确保WHERE条件命中索引以避免表锁，并配合INSERT ... ON DUPLICATE KEY UPDATE处理“查再插”竞态；READ COMMITTED下需警惕幻读，跨服务场景须依赖应用层幂等或分布式事务。

用 `SELECT ... FOR UPDATE` 锁住要更新的行

在事务中修改某条记录前，必须先加行级写锁，否则并发读-改-写会导致覆盖或丢失更新。比如两个事务同时读取余额为 100 的账户，各自加 50 后写回，最终变成 150 而不是预期的 200。

正确做法是在 BEGIN 后立即执行带锁查询：

START TRANSACTION;
SELECT balance FROM accounts WHERE id = 123 FOR UPDATE;
-- 此时其他事务对 id=123 的行执行 SELECT ... FOR UPDATE 或 UPDATE 会被阻塞
UPDATE accounts SET balance = balance + 50 WHERE id = 123;
COMMIT;

注意：FOR UPDATE 只在可重复读（REPEATABLE READ）隔离级别下才真正锁定索引覆盖的行；如果 WHERE 条件没走索引，会升级为表锁。

避免长事务 + 显式控制锁范围

锁持有时间越长，阻塞越多，死锁概率越高。常见错误是把耗时操作（如 HTTP 调用、文件读写）放进事务里。

只把真正需要原子性的 DB 操作包进事务
确保 WHERE 条件命中主键或唯一索引，避免锁住不相关行
批量更新时，分页或按主键范围拆成多个小事务，不要一次 UPDATE ... LIMIT 10000
确认 autocommit 关闭（SET autocommit = 0），否则每条语句自动提交，FOR UPDATE 失效

用 `INSERT ... ON DUPLICATE KEY UPDATE` 替代“查再插”

“先查是否存在，不存在则插入”这种逻辑在并发下必然产生竞态：两个事务都查到不存在，然后都插入，触发唯一键冲突或重复数据。

直接用原子语句替代：

INSERT INTO user_points (user_id, points) 
VALUES (123, 10) 
ON DUPLICATE KEY UPDA
TE points = points + 10;

前提是 user_id 有唯一约束（主键或 UNIQUE 索引）。该语句内部由 MySQL 自动处理冲突，不会报错也不会丢更新。

注意：如果业务需要区分“本次是插入还是更新”，可通过 ROW_COUNT() 判断影响行数，但不能依赖 LAST_INSERT_ID() —— 它在 ON DUPLICATE KEY UPDATE 场景下行为不可靠。

读已提交（`READ COMMITTED`）下慎用非锁定读

默认的 REPEATABLE READ 隔离级别能防止不可重复读，但代价是间隙锁（Gap Lock）更重；而 READ COMMITTED 下每次 SELECT 都读最新已提交版本，不加间隙锁，看似轻量，却容易引发幻读问题——尤其在“检查约束+插入”类逻辑中。

例如判断订单号未被使用，然后插入新订单：

事务 A 查 SELECT COUNT(*) FROM orders WHERE order_no = 'NO2025001' → 0
事务 B 插入 'NO2025001' 并提交
事务 A 继续插入 → 唯一键冲突

这种场景不能靠隔离级别解决，必须用 SELECT ... FOR UPDATE 或唯一索引+INSERT ... ON DUPLICATE KEY UPDATE 这类原子机制兜底。

真正难处理的不是单条 SQL 的一致性，而是跨表、跨服务、含外部依赖的业务逻辑。MySQL 的锁和事务只能保它自己那块数据，一旦涉及 Redis 缓存更新、MQ 发消息、第三方支付回调，就得靠应用层补偿、幂等设计或分布式事务框架来兜住——这些已经超出 MySQL 本身能力范围了。

# mysql # redis # red # sql # 分布式 # count # for # select # 并发 # http # 主键 # 不存在 # 死锁 # 一键 # 锁住 # 应用层 # 是在 # 多个 # 这类 # 分页

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】