Lock wait timeout exceeded 根本原因是事务被行锁阻塞超时，而非查询慢；需先查锁等待（data_lock_waits 或 INNODB_TRX），再分析诱因如未提交事务、长事务、索引失效等，而非盲目调大超时参数。
看到 Lock wait timeout exceeded，先别急着调大超时
这个错误不是查询慢，而是事务卡在行锁上等太久被 mysql 主动中断了。典型表现是：某条 UPdate 或 delete 执行几秒就报错，但单独 select 很快；日志里带 try restarting transaction。
- 先查谁在锁：
SELECT * FROM performance_schema.data_lock_waits;（MySQL 8.0+）或SELECT * FROM information_schema.INNODB_TRX;+INNODB_LOCKS（5.7） - 重点看
trx_mysql_thread_id和trx_state，找出长时间RUNNING或LOCK WAIT的线程 - 别直接
KILL生产事务——先确认它是不是业务关键操作；更稳妥的是加监控表，用 Event 定期落库锁等待上下文 - 常见诱因：未提交的事务、长事务里混了
SLEEP()、应用端没设transaction timeout、批量更新没分页
EXPLAIN 显示 type=ALL？那不是超时，是根本没走索引
很多所谓“查询超时”，其实是执行计划崩了——全表扫描百万行，自然卡死。别一上来就改 wait_timeout 或 max_execution_time，先看优化空间。
-
rows值远大于实际结果集？说明索引没生效或选错了；检查key列是否为NULL - WHERE 条件字段类型和参数不一致（比如
varCHAR字段传数字），会触发隐式转换，索引直接失效 - 复合索引顺序很重要：
WHERE a = ? AND b > ? ORDER BY c，推荐建INDEX(a, b, c)，而不是分开三个单列索引 - 避免在索引列上用函数：
WHERE DATE(create_time) = '2026-01-01'→ 改成WHERE create_time >= '2026-01-01' AND create_time
慢查询日志开了，但日志里全是 SELECT 1？那是连接池健康检查刷屏
这说明你配置的 long_query_time 太低，或者没过滤掉无意义的探测语句，真正慢的业务 SQL 反而被淹没。
- 确认是否启用了
log_queries_not_using_indexes——关掉它，否则索引缺失的SELECT 1也会进慢日志 - 生产建议设
long_query_time = 1.0（不是 0.1），再配合min_examined_row_limit = 1000过滤低价值扫描 - 用
pt-query-digest /var/log/mysql/slow.log --filter '$event->{Bytes} > 1024'排除小结果集干扰 - 别只看
mysqldumpslow -s t（按时间排序），更要跑pt-query-digest --report-format profile看哪类查询占 CPU 最多
HikariCP 报 Communications link failure？MySQL 没断网，是它自己“踢人”了
这不是网络问题，是 MySQL 服务端主动关闭了空闲连接，而连接池没及时发现并剔除——下一次请求拿了个已断的连接去发 SQL，才爆这个错。
- 必须同步调大 MySQL 的两个超时：
wait_timeout和interactive_timeout，只改一个无效（JDBC 初始化时按协议类型选其一） - 代码侧比调参更可靠：开 HikariCP 的
validation-timeout=3000+max-lifetime=1800000（30 分钟强制换新连接） - 禁用
autoReconnect=true——MySQL 5.5+ 已废弃，且会掩盖连接泄漏，让问题延迟暴露 - docker 环境改配置别忘挂载：
-v /host/my.cnf:/etc/mysql/conf.d/custom.cnf，改完必须docker restart mysql，reload 不生效
真正难处理的从来不是单一超时参数，而是多个机制叠加失效：MySQL 踢了连接，连接池没检测，应用又没重试逻辑，最后堆栈里只留一句模糊的 “connection reset”。排查时一定从错误信息里的关键词出发，别凭感觉调参。