事务隔离级别选错会导致大量锁等待
高并发下最常见问题是
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 状态。这类问题不会出现在慢查询日志里，但会持续压低系统水位。
