事务粒度太大导致锁等待超时
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，关键在识别哪部分操作真正需要原子性、哪部分可以松耦合。最容易被忽略的是：唯一约束检查和插入动作是否必须在一个事务里完成——很多时候答案是否定的。
