高并发写场景下应精细控制锁粒度：优先行锁且必须走索引，避免全表锁；合理设计主键，禁用函数索引失效；按需降级隔离级别至 READ COMMITTED；批量写入并拆分小事务；用原子更新替代先查后改；监控锁等待并收敛热点，必要时用 Redis+ 异步落库。
高并发写场景下，锁粒度控制直接决定系统吞吐量和响应稳定性。核心不是“要不要加锁”，而是“锁多小、锁多久、锁哪里”——粒度越细、持有时间越短、范围越精准，并发能力越强。
优先用行锁，但必须走索引
InnoDB 的行锁只在通过索引（主键或唯一 / 普通索引）定位数据时生效。如果 UPDATE 或 DELETE 语句的 WHERE 条件未命中任何索引，InnoDB 会退化为锁全表（实际是逐行加锁，效果等同表级阻塞）。
- 检查执行计划：对高频写语句运行 EXPLAIN，确认 type 字段为 const、ref 或 range，避免 ALL
- 主键设计要合理：用自增整型而非 UUID，减少 B+ 树分裂与间隙锁扩散
- 避免在 WHERE 中对字段做函数操作，如 WHERE DATE(create_time) = ‘2026-01-05’ 会失效索引
按业务节奏调整隔离级别
默认的 REPEATABLE READ 会启用间隙锁（Gap Lock），防止幻读，但也扩大了锁范围。在写密集且可接受“已提交读”语义的场景中，降级为 READ COMMITTED 能显著减少锁冲突。
- 适用场景：订单流水记录、日志表写入、用户行为埋点等无需可重复读保障的业务
- 副作用：可能出现不可重复读，需应用层校验关键状态（如余额是否充足）
- 配置方式：SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
批量写入 + 小事务拆分
单条 INSERT/UPDATE 意味着一次加锁、一次日志刷盘、一次事务提交开销。高并发写应合并操作，同时控制事务边界。
- 用 INSERT INTO t VALUES (…), (…), (…) 替代多条单行插入，每批 500–1000 行较优
- 避免跨多业务逻辑的大事务，例如“扣库存 + 写订单 + 发消息”应拆成独立事务，用最终一致性补偿
- 写入前先查再更新（SELECT + UPDATE）易引发竞争，改用 UPDATE … SET x = x – 1 WHERE id = ? AND x >= 1 原子判断
监控与收敛锁等待 热点
锁问题往往集中在少数热数据上，比如商品 ID= 1 的库存行、用户 ID=1000001 的账户余额。不靠猜，要靠看。
- 实时查看锁等待：SELECT * FROM information_schema.INNODB_TRX; 和 INNODB_LOCK_WAITS
- 定位热点行：SHOW ENGINE INNODB STATUSG 中的 LATEST DETECTED DEADLOCK 及 TRANSACTIONS 部分
- 长期方案：对超高频单行写入（如计数器），改用 Redis 原子操作 + 异步落库，MySQL 只承担持久化角色
