MySQL：Lock wait timeout exceeded； try restarting transaction

错误类型及根因分析

1. Lock wait timeout exceeded; try restarting transaction

• 原因：事务等待行锁/表锁超时报错（由 innodb_lock_wait_timeout 控制，默认50秒），说明存在 锁竞争或长事务，导致后续事务等待锁超时。
• 关联影响：高频出现会拖慢业务，甚至引发死锁风险。

2. Got an error writing communication packets

• 原因：MySQL 向客户端发送数据时失败，可能是：
  • 网络问题：客户端断开连接、网络延迟/丢包，导致 MySQL 写数据到 socket 失败；
  • 连接超时：客户端或服务端连接超时（如 wait_timeout 过短，客户端提前断开）；
  • 大数据包：查询结果过大，超出 max_allowed_packet 限制，导致发包中断。

核心解决思路

针对锁等待超时：

1. 排查长事务：执行 SELECT * FROM information_schema.INNODB_TRX，查看运行时间长的事务，优化其逻辑（拆分事务、减少锁持有时间）。
2. 调整锁等待时间：若业务允许，临时调大 innodb_lock_wait_timeout（需权衡，非根治方法）。
3. 优化索引/业务逻辑：检查慢查询，确保热点行/表的操作加锁合理（如避免全表扫描导致的锁范围过大）。

针对通信包错误：

1. 网络排查：在客户端和服务端抓包（如 tcpdump），检查网络延迟、丢包；确保中间件（负载均衡、代理）无连接中断。
2. 调整连接参数：
   • 调大 max_allowed_packet（避免大结果包被截断）；
   • 延长 wait_timeout/interactive_timeout（避免连接被过早回收）。
3. 客户端侧检查：确保客户端代码捕获连接异常，避免异常断开后服务端仍尝试写数据。

总结

• 锁等待：聚焦 事务优化 + 锁竞争治理（长事务、索引合理性）；
• 通信错误：聚焦 网络稳定性 + 连接超时配置 + 数据包大小限制。
  优先从业务高峰时段的慢查询、事务日志入手，结合监控工具（如 Percona Monitor）定位具体会话和 SQL。