MySQL报错MY-011567导致会话被杀，远程修复故障经验分享

那次故障发生在一个周三的下午，业务高峰期刚过，但系统监控平台突然开始频繁报警，报警信息显示，有几台核心的MySQL数据库从库出现了大量应用连接中断的情况,我们赶紧登录到服务器上查看。

我们检查了MySQL的错误日志，这是最直接能找到问题根源的地方，在日志里，我们看到了大量重复出现的报错信息，核心内容是这样的： [Warning] [MY-011567] [InnoDB] The total number of locks exceeds the lock table size. Waiting for server main loop to free some locks. 紧接着这些警告之后，就会出现一些用户会话被强制终止的记录，类似于： [Note] [MY-013183] [InnoDB] Assertion failure: thread 12345, file /path/to/lock0lock.cc, line 1234 ... Aborting connection for user 'app_user' from host '10.0.1.100' ...

看到这个，我们心里基本有数了，这个MY-011567错误，说白了就是数据库的“锁桌子”不够大了，MySQL有一个专门用来管理锁信息的内存区域，叫做innodb_buffer_pool_size（缓冲池）之外的lock_sys结构（来源：MySQL官方文档对InnoDB锁系统的描述），当同时进行的事务太多，或者某些事务锁住了非常多的数据行（比如一个没有索引的大表全表更新），产生的锁信息总量超过了预先分配的内存大小，这个“锁桌子”就摆不下了，这时候，数据库就会卡住，为了避免整个数据库崩溃，它就会选择杀掉一些正在执行的事务来释放锁资源,这就是我们看到的会话被杀的根本原因。

确认了问题，接下来就是远程修复，由于是线上从库，首要目标是快速恢复同步，避免主从延迟越来越大,我们采取了以下步骤：

第一步：紧急缓解 我们立刻登录到受影响的从库MySQL命令行，执行了命令： SHOW ENGINE INNODB STATUS\G 这个命令能输出非常详细的InnoDB引擎状态信息，我们重点查看了TRANSACTIONS部分，这里会显示当前活跃的事务、它们持有的锁数量以及等待锁的事务，果然，我们发现有一个来自数据统计任务的查询事务，因为操作不当（对一个大表进行了没有WHERE条件的更新测试），它一个人就占用了海量的行锁，成了“罪魁祸首”，由于这个事务已经卡死，我们果断使用命令： KILL QUERY [该事务的线程ID]; 先终止了它的查询，但有时候这还不够，如果事务本身状态异常，可能需要KILL CONNECTION来彻底结束整个会话，操作后，我们观察到等待锁的线程数迅速下降,数据库的写入和复制线程逐渐恢复正常。

第二步：根本解决 杀掉异常会话只是临时救火，为了防止问题再次发生，必须调整数据库参数，核心参数就是innodb_buffer_pool_size和innodb_lock_wait_timeout。

1. 增大锁容量：虽然锁信息不直接存放在缓冲池里，但增大innodb_buffer_pool_size可以间接提升整个InnoDB的性能和并发处理能力，更重要的是，我们需要确保系统有足够的空闲内存，我们检查了服务器的空闲内存（使用free -h命令），发现确实有盈余，我们通过远程配置管理工具，在线动态调整了参数（MySQL 5.7及以上版本支持）： SET GLOBAL innodb_buffer_pool_size = 2147483648; -- 例如从1G增大到2G 这个设置无需重启即刻生效,但调整过程中可能会引起数据库性能的短暂波动。
2. 优化事务：这是更重要的长期措施，我们联系了开发团队，指出了那个导致问题的低效查询，建议他们：
   • 为查询条件添加合适的索引,避免全表扫描和锁定。
   • 将大事务拆分成多个小事务，及时提交,减少单次事务持有的锁数量和时长。
   • 检查业务代码,避免在事务内进行不必要的长时间操作。

第三步：复盘与加固 故障解决后，我们进行了复盘，这次事件暴露了两个问题：一是对特定类型的批量操作监控不足；二是数据库的部分参数配置过于保守，没有随着业务增长及时调整。 我们因此加强了监控，增加了对Innodb_row_lock_time_avg（平均行锁等待时间）和Innodb_row_lock_waits（行锁等待次数）等指标的监控告警，我们也制定了定期的数据库配置评审机制,确保参数配置能跟上业务发展的步伐。

总结这次远程修复MY-011567错误的经验，关键点在于：快速定位日志 -> 分析锁竞争状况 -> 紧急终止问题会话 -> 合理调整系统参数 -> 从业务层面优化SQL和事务逻辑，整个过程要求运维人员对MySQL的锁机制有清晰的理解，并且能够熟练运用命令行工具进行远程诊断和操作，最重要的是，不能只满足于临时解决，一定要追根溯源,通过优化设计和配置来杜绝同类故障的再次发生。