应拆分大事务为每批100~500行的小事务并及时COMMIT，避免长事务锁表、MVCC膨胀及主从延迟；高频更新宜用单条UPDATE代替查改分离，唯一约束冲突优先用INSERT IGNORE或应用层Redis幂等控制。
事务粒度太大导致锁等待超时
MySQL 在并发写入时，如果一个事务包含大量 UPDATE 或 INSERT 操作，很容易长时间持有行锁或间隙锁，其他事务在等锁时触发 Lock wait timeout exceeded。这不是数据库扛不住，而是事务把锁占得太久。
实操建议：
- 把单个大事务拆成多个小事务，每批处理
100~500行（具体看单行数据大小和索引复杂度） - 用
WHERE id BETWEEN ? AND ?或WHERE id > ? ORDER BY id LIMIT 500分页，避免OFFSET越往后越慢 - 拆分后每个事务末尾加
COMMIT，确保锁及时释放；不要依赖自动提交（autocommit=0时尤其危险） - 避免在事务中调用外部 HTTP 接口、文件读写等长耗时操作
高频更新场景下减少事务内竞争
比如秒杀扣减库存、计数器累加这类操作，多个事务同时更新同一行，必然排队。即使用了 SELECT ... FOR UPDATE，也挡不住锁冲突。
实操建议：
- 把「查 + 改」逻辑下沉到一条
UPDATE语句里，例如：UPDATE goods SET stock = stock - 1 WHERE id = 123 AND stock >= 1;
成功影响行数为1才算扣减成功，否则直接失败重试 - 对非核心字段（如浏览量、点赞数），改用异步写入或 Redis 计数 + 定期合并回 MySQL，避开事务锁
- 如果必须多行更新且有强一致性要求，考虑按业务主键哈希分片，比如
user_id % 16，让不同用户落在不同事务批次里，天然降低冲突概率
唯一约束冲突引发隐式锁升级
当多个并发事务尝试插入相同 UNIQUE KEY 的记录时，MySQL 不仅会报 Duplicate entry，还会在失败前加间隙锁（gap lock），阻塞后续插入——这是很多人没意识到的“失败也锁表”现象。
实操建议：
- 插入前先
SELECT ... LOCK IN SHARE MODE判断是否存在，但要注意这本身也会加锁，不如改用INSERT IGNORE或ON DUPLICATE KEY UPDATE，它们在冲突时不会升级锁 - 对高并发唯一写入场景（如发券码生成），提前在应用层用 Redis
SETNX做轻量级幂等控制，避免大量请求打到 MySQL - 确认是否真的需要
UNIQUE约束：有时业务上允许少量重复，可改由应用层去重 + 后台任务清理，换取并发吞吐
长事务拖慢 MVCC 清理与主从延迟
MySQL 的 undo log 不能被 purge，只要有一个活跃长事务存在，所有已提交事务的旧版本都得保留。这不仅让 ibdata1 膨胀，还会让从库复制线程卡在 Waiting for dependent transaction。
实操建议：
- 监控
information_schema.INNODB_TRX表，定期查TIME_TO_SEC(NOW() - trx_started) > 60的事务，定位是哪个服务/接口没及时提交 - 在应用代码里给事务加超时兜底，比如 Spring 的
@Transactional(timeout = 30)，或 MyBatis-Plus 的SqlSessionTemplate设置defaultExecutorType - 避免在事务里做分页查询（
SELECT ... LIMIT）后再循环更新，这种模式极易因前端响应慢而拉长事务时间
事务拆分不是简单切几段 SQL，关键在识别哪部分操作真正需要原子性、哪部分可以松耦合。最容易被忽略的是：唯一约束检查和插入动作是否必须在一个事务里完成——很多时候答案是否定的。
