MySQL连接空闲超时（wait_timeout/interactive_timeout）设为300秒可防锁残留；innodb_lock_wait_timeout建议10～25秒以平衡死锁感知与误判；需避免事务内非DB操作、N+1查询及用max_execution_time控DML。
wait_timeout 和 interactive_timeout 设定不合理导致连接空闲锁残留
MySQL 的 wait_timeout 控制非交互式连接空闲超时，interactive_timeout 控制交互式连接（如 mysql 客户端）空闲超时。两者默认通常是 28800 秒（8 小时），远超业务实际需要——连接长期挂着，事务没提交、语句没执行完，就可能持续持有行锁或表锁。
实操建议：
- 根据应用连接池行为设值：若用 HikariCP 或 druid，连接池回收逻辑应与 MySQL 超时对齐；通常设
wait_timeout = 300（5 分钟）更安全 - 确认客户端类型：Java JDBC 默认是非交互式，只受
wait_timeout影响；命令行登录才走interactive_timeout - 避免两端不一致：应用层设置
socketTimeout或connectTimeout不能替代服务端超时，后者才是锁释放的最终防线 - 修改后需重启连接池或等待旧连接自然淘汰，否则不会立即生效
innodb_lock_wait_timeout 设置过长放大死锁感知延迟
innodb_lock_wait_timeout 决定一个事务在等锁时最多忍多久，默认 50 秒。设太高，会让“卡住”的事务迟迟不报错，下游请求堆积、线程阻塞、监控失真；设太低（如 1 秒），又容易把正常竞争误判为超时，增加重试压力。
实操建议：
- 从慢查询日志里找
Lock wait timeout exceeded出现前的 SQL，分析是否真有长事务或未索引 WHERE 条件——超时只是表象，锁争抢根源常在 SQL 本身 - OLTP 场景建议设为 10～25 秒：足够覆盖网络抖动和轻量级锁等待，又不至于让单个卡顿拖垮整个接口
- 不要全局统一：可对关键事务用
SET innodb_lock_wait_timeout = 5临时调低，配合应用层快速失败策略 - 注意它不影响死锁检测（那是
innodb_deadlock_detect控制的），只管“等锁等到放弃”
应用端未显式控制事务边界引发隐式长事务
很多框架（如 Spring 的 @Transactional）默认传播行为是 REQUIRED，但开发者常忽略方法内调用耗时操作（HTTP 请求、文件读写、循环处理），导致事务实际持锁时间远超预期——MySQL 不知道你在等外部服务，它只认 BEGIN 到 COMMIT/ROLLBACK 的时长。
实操建议：
- 用
SHOW PROCESSLIST查看Command为Sleep但Time值很大的连接，再结合information_schema.INNODB_TRX看其TRX_STARTED时间，定位“挂起的事务” - 禁止在事务内做非 DB 操作；必须做的，拆成“查 → 提交 → 处理 → 再更新”两段式
- 开启
innodb_print_all_deadlocks = ON并定期扫错误日志，比等监控告警更早发现模式化锁冲突 - ORM 层注意 fetch 策略：Hibernate 的 N+1 查询可能在事务中触发大量隐式 SQL，间接延长锁持有
max_execution_time 对 DML 无效，别指望它防 UPDATE 锁表
max_execution_time 只对 SELECT 生效（5.7.8+），对 INSERT/UPDATE/DELETE 完全无感。有人想靠它“限时更新百万行”，结果 UPDATE 卡住，锁住整张表，其他查询全被堵死。
实操建议：
- 批量更新必须分页：用
WHERE id BETWEEN ? AND ?+ 限行（LIMIT），每次不超过 5000 行，中间 COMMIT - 大表 DML 前先加
SELECT ... FOR UPDATE预占锁并检查影响行数，避免 UPDATE 执行一半才发现条件错 - 真正要控 DML 时长，得靠应用层计时+中断，或使用
KILL QUERY配合脚本监控（但注意 KILL 不保证立刻释放锁） - DDL 更危险：
ALTER TABLE在 5.6+ 支持 online DDL，但仍可能在某些操作（如改列类型）中短暂锁表，别把它和 DML 混为一谈
超时不是万能开关，它只解决“该放手时不硬扛”的问题。真正难的，是判断哪条 SQL 本不该持有锁、哪个事务本不该跨服务调用、哪次重试其实是在恶化雪崩。这些没法靠配置一行解决。
