高并发读写冲突本质是事务间资源竞争，需依业务选锁类型、隔离级别及SQL设计；MySQL默认可重复读下UPDATE加行锁与间隙锁，读多写少可降为读已提交，写操作须走索引，低冲突可用乐观锁，热点数据宜分片，辅以读写分离与缓存。
高并发下读写冲突本质是多个事务同时访问同一数据时的资源竞争问题，核心不在“加不加锁”，而在“加什么锁、什么时候加、加多久”。盲目用大粒度锁（比如表锁）会严重拖慢性能，而完全不用锁又会导致脏读、幻读等一致性问题。关键得根据业务场景选对锁类型和隔离级别，并配合合理的SQL设计。
读懂锁类型和隔离级别的实际影响
MySQL默认可重复读（REPEATABLE READ）下，普通SELECT不加锁，但UPDATE/DELETE会加行级记录锁（Record Lock），范围查询还会加间隙锁（Gap Lock）防幻读。这意味着即使你只更新一行，若WHERE条件走不了索引，可能升级为表锁；若WHERE命中索引但范围较大（如WHERE id > 100），间隙锁会锁住整个空隙，阻塞其他插入。
- 读多写少场景：考虑把事务隔离级别降为读已提交（READ COMMITTED），它不加间隙锁，能显著减少锁冲突，但需接受不可重复读
- 写操作务必确保WHERE条件走索引，否则InnoDB会退化为表锁——用
EXPLAIN确认执行计划 - 避免在事务里做耗时操作（如调外部API、复杂计算），缩短锁持有时间
用乐观锁替代悲观锁，适合低冲突写场景
当写冲突概率低（比如用户修改个人资料），与其让数据库一直锁着记录，不如用版本号或时间戳做CAS更新。每次UPDATE带上当前版本值，只在版本未变时才成功，失败由应用重试。
- 建表加
version INT DEFAULT 0字段，UPDATE语句写成：UPDATE t SET name='x', version=version+1 WHERE id=123 AND version=5 - 检查
ROW_COUNT()是否为1，不是则说明被别人抢先改了，应用层决定重试或提示 - 注意：不能替代事务一致性，仍需包裹在事务中保证原子性
拆分热点行，从源头减少争抢
像账户余额、商品库存这类高频更新字段，单行就是天然热点。可通过哈希拆分或逻辑分片，把一个值分散到多行，更新时随机选一行操作，最后聚合查总数。
- 例如库存表增加
shard_id TINYINT，共4个分片，更新时WHERE sku_id='A' AND shard_id = FLOOR(RAND()*4) - 查总库存时
SELECT SUM(stock) FROM stock_shard WHERE sku_id='A' - 适合最终一致性可接受的场景，且需配套幂等和补偿机制
读写分离 + 缓存兜底，降低数据库压力
锁冲突加剧往往因为数据库扛了太多请求。把实时性要求不高的读请求导到从库，高频读（如商品详情）用Redis缓存结果，并设好过期策略和更新双删逻辑。
- 写操作后先删缓存，再更新DB；延迟一段时间（如500ms）再删一次，覆盖主从同步延迟期间的脏读
- 从库延迟监控必须做，延迟超阈值时自动切回主库读（代价高但保一致）
- 缓存击穿问题用互斥锁（如Redis SETNX）保护，防止海量请求穿透到DB
锁不是越细越好，也不是越少越好。真正有效的优化，是结合业务语义判断哪些操作必须强一致、哪些可以妥协，再选工具。很多“高并发问题”，其实卡在没走索引、事务包太大、或者缓存没用对地方。
