事务隔离级别选错、长事务、批量操作不当及死锁是高并发下四大典型问题：REPEATABLE READ易触发间隙锁；长事务延长锁持有时间；单条循环插入放大锁冲突；死锁暴露资源访问顺序混乱。
事务隔离级别选错会导致大量锁等待
高并发下最常见问题是 REPEATABLE READ 隔离级别触发间隙锁（Gap Lock），导致无关记录被锁住，尤其在 WHERE 条件命中索引范围时。比如执行 UPDATE orders SET status = 1 WHERE user_id = 123 AND created_at > '2024-01-01'，即使只改一行，也可能锁住整个索引区间。
实操建议：
- 确认业务是否真的需要可重复读：多数 Web 应用用
READ COMMITTED就够了，它不加间隙锁，只锁命中的行 - 临时切换可用
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED，但需配合应用层重试逻辑处理幻读 - 若必须用
REPEATABLE READ，确保WHERE条件走**唯一索引**或**主键**，避免范围扫描触发间隙锁
长事务是并发吞吐的隐形杀手
事务持续时间越长，持有锁和 undo log 的时间就越久，其他事务卡在 Waiting for table metadata lock 或 Waiting for X lock on ... 的概率就越高。一个 5 秒未提交的事务，可能让上百个请求排队。
实操建议：
- 禁止在事务里做 HTTP 调用、文件读写、sleep 等非数据库操作
- 用
SHOW PROCESSLIST定期查Time列 > 1s 的Command为Sleep或Query的连接，结合INFO列定位长事务 SQL - 在应用层设置事务超时，如 Spring 的
@Transactional(timeout = 3)，或 MyBatis 的defaultStatementTimeout
批量更新别用单条 INSERT/UPDATE 循环
在事务中循环执行 1000 次 INSERT INTO t (a,b) VALUES (?,?)，不仅网络往返多，还会让锁粒度放大（InnoDB 默认行锁，但大量单语句会提高锁冲突概率），且 undo log 增长快，容易触发 Lock wait timeout exceeded。
实操建议：
- 改用批量语法：
INSERT INTO t (a,b) VALUES (1,2),(3,4),(5,6)，单条语句最多 1000 组值（受max_allowed_packet限制） - 对大批次，分段提交：每 100–500 行 commit 一次，避免单事务过大；注意分段依据字段必须有索引，防止全表扫描
- 考虑用
LOAD DATA INFILE替代大批量插入，速度提升 5–10 倍，但需确保文件可被 MySQL 服务端访问
死锁不是故障，而是设计信号
Deadlock found when trying to get lock 错误本身不可怕，可怕的是反复出现同一类死锁。它说明多个事务以不同顺序访问相同资源，比如事务 A 先更新用户表再更新订单表，事务 B 反过来操作，就必然死锁。
实操建议：
- 用
SHOW ENGINE INNODB STATUS\G查看最近死锁详情，重点关注TRANSACTION下的mysql tables in use和LOCK WAIT部分 - 统一所有业务模块的表操作顺序：例如约定「总是先操作
user，再order，最后log」 - 对高频更新的热点行（如账户余额），用
SELECT ... FOR UPDATE ORDER BY id ASC LIMIT 1强制顺序加锁，避免随机竞争
真正难调的从来不是单点性能，而是事务边界与业务逻辑耦合的方式——比如把库存扣减和消息发送塞进同一个事务，既拖慢数据库，又让消息可靠性依赖 DB 状态。这类问题不会出现在慢查询日志里，但会持续压低系统水位。
