MySQL高并发数据一致性需综合事务隔离级别、锁机制、原子操作与应用设计：默认REPEATABLE READ防脏读和不可重复读，SERIALIZABLE防幻读但降性能；常用SELECT ... FOR UPDATE加行锁配READ COMMITTED；行锁需索引支持，热点数据可用悲观锁（WHERE校验）或乐观锁（version字段）；避免长事务，控制批量大小；分布式场景采用最终一致性，如本地消息表+MQ+补偿机制。
MySQL在高并发场景下保障数据一致性，核心在于合理利用事务隔离级别、锁机制、原子操作和应用层协同设计，而不是单纯依赖某一种技术。
合理设置事务隔离级别
默认的REPEATABLE READ能避免脏读和不可重复读，但无法彻底解决幻读；若业务对实时一致性要求极高（如库存扣减、资金划转），可考虑升级为SERIALIZABLE，但会显著降低并发性能。更常见的做法是：在关键业务中用SELECT ... FOR UPDATE显式加行锁，配合READ COMMITTED隔离级别，在保证一致性的同时减少锁冲突。
用好行级锁与乐观锁结合
InnoDB默认使用行锁，但需确保查询条件命中索引，否则会退化为表锁。对高频更新的热点数据（如商品库存），推荐两种策略：
- 悲观锁：执行UPDATE t SET stock = stock - 1 WHERE id = ? AND stock >= 1，靠WHERE条件+影响行数判断是否扣减成功
- 乐观锁：增加version字段，更新时校验SET version = version + 1 WHERE id = ? AND version = ?，失败则重试
避免长事务与大事务
事务越长，持有锁时间越久，越容易引发死锁和阻塞。应做到：
- 只在真正需要ACID的地方开启事务，非必要不跨服务、不跨HTTP请求维持事务
- 批量操作拆分为小批次，单次事务操作控制在百行以内
- 及时提交或回滚，不在事务中做RPC调用、文件读写、sleep等耗时操作
分布式场景下引入最终一致性补偿
当涉及多个数据库或微服务（如订单库+库存库+积分库），强一致难以实现，应转向“可靠事件+本地消息表+定时校对”模式：
- 在本地事务中写业务数据+写入消息表（状态为“待发送”）
- 事务提交后异步发送MQ，消费成功再更新消息表状态
- 独立补偿服务扫描超时未确认的消息，重新投递或告警人工介入
不复杂但容易忽略。关键不是堆砌技术，而是根据业务容忍度选择合适的一致性模型——强一致用于资金类，最终一致用于日志、通知、统计类。
