MySQL删除8000条记录超时（错误码2013）技术求助

针对你遇到的小表删除超时、报Error Code: 2013. Lost connection to MySQL server during query的问题，给出以下排查和优化方案：

• 调整连接超时参数
  你设置的innodb_lock_wait_timeout是控制锁等待的超时时间，但2013错误属于连接层面的超时，和wait_timeout/interactive_timeout参数直接相关。先查看当前参数值：

  SHOW VARIABLES LIKE 'wait_timeout';
  SHOW VARIABLES LIKE 'interactive_timeout';
  

  如果参数值较小，临时调整会话级别的超时时间：

  SET SESSION wait_timeout = 3600;
  SET SESSION interactive_timeout = 3600;
  

• 优化删除语句效率

  1. 添加必要索引：确保data.table和tempTable的KP字段都有索引，否则JOIN或IN子查询会触发全表扫描，即使是小表也可能拖慢执行速度：

     CREATE INDEX idx_table_kp ON data.table(KP);
     CREATE INDEX idx_temptable_kp ON tempTable(KP);
     

  2. 分批次删除：一次性删除8000条会持有锁时间过长，分批次删除能减少资源占用，避免连接超时：

     USE data;
     SET SQL_SAFE_UPDATES=0;
     SET innodb_lock_wait_timeout = 3000;
     SET SESSION wait_timeout = 3600;
     
     REPEAT
       DELETE a
       FROM data.table AS a
       JOIN tempTable AS b ON a.KP = b.KP
       WHERE a.KP IS NOT NULL
       LIMIT 1000;
     UNTIL ROW_COUNT() = 0 END REPEAT;
     

• 排查锁冲突
  可能存在未提交的长期事务占用锁，导致你的删除操作一直等待最终触发连接超时。可以查看当前运行的事务和锁状态：

  SELECT * FROM information_schema.INNODB_TRX;
  SHOW ENGINE INNODB STATUS;
  

  找到长时间未提交的事务，协调业务端提交或回滚，释放锁资源。

• 更新表统计信息与整理碎片
  小表如果统计信息过时或碎片过多，会导致优化器选择低效执行计划：

  -- 更新统计信息，无锁表风险
  ANALYZE TABLE data.table;
  -- 整理碎片，会锁表，建议低峰期执行
  OPTIMIZE TABLE data.table;
  

内容的提问来源于stack exchange，提问作者nmhicks