MySQL报错ER_IB_WARN_MANY_NON_LRU_FILES_OPENED怎么修复远程处理经验分享

那次是半夜接到电话，说一个核心业务的数据库突然变得非常慢，应用日志里满是连接超时的错误，远程连上服务器后，第一件事就是查看MySQL的错误日志，在一堆正常运行的记录里，我看到了几条刺眼的警告信息，大意是“ER_IB_MSG_824”和“ER_IB_WARN_MANY_NON_LRU_FILES_OPENED”（根据MySQL官方文档和Percona博客的相关讨论，这类消息通常关联于InnoDB表空间文件打开数过多的问题），虽然只是“警告”级别，没有导致实例崩溃，但数据库的响应速度已经慢得像蜗牛,明显是这个问题引发的。

我当时的第一反应是，这肯定和InnoDB的打开文件限制有关，InnoDB有一个叫LRU（最近最少使用）的列表，用来管理那些最活跃的表空间文件（比如每个独立表空间对应的.ibd文件），保证常用的文件能快速被访问，但当同时打开的表空间文件数量超过某个限度时，多出来的文件就会被归类为“non-LRU”文件，这个警告就是在说：“喂，哥们，同时打开的非核心文件太多了，我快忙不过来了！”（这个机制的解释，参考了MySQL官方手册中关于InnoDB缓冲池和文件管理的章节）。

接下来就是定位原因，我用了几个命令来核实情况，我查看了MySQL当前的打开文件数限制：show variables like 'open_files_limit'; 然后又看了InnoDB自己的设置：show variables like 'innodb_open_files'; 发现 innodb_open_files 的值设置得比较低，只有几千，紧接着，我统计了一下数据库中实际有多少个表（因为每个独立表空间都对应一个文件）：select count(*) from information_schema.tables where table_schema not in ('mysql', 'information_schema', 'performance_schema', 'sys'); 结果发现表数量远远超过了 innodb_open_files 的限制，这就对上了！当表非常多时，即使只是进行简单的查询，也可能瞬间触发大量文件打开操作，导致超过限制,从而出现警告和性能骤降。

找到根因后，修复方案就清晰了，核心思路就是提高InnoDB能够同时管理的文件数量上限，直接在运行的实例上修改动态变量 innodb_open_files 是行不通的，因为它是只读的，必须在配置文件里设置并重启才能生效（根据MySQL官方文档，innodb_open_files 是一个静态参数），这就带来了一个难题：这是核心业务库,白天不能随便重启。

我们制定了一个临时的缓解措施和一个永久的修复方案。临时方案是：立刻与应用团队沟通，清理掉一些肯定不再使用的临时表或历史归档表，减少物理文件的数量，暂时缓解压力，密切监控数据库的性能指标。永久方案则安排在下一个业务低峰期（比如深夜）进行：

1. 修改MySQL的配置文件（通常是my.cnf或my.ini）。
2. 适当调高 open_files_limit 的值，这个值是整个MySQL实例能打开的文件数上限，必须大于 innodb_open_files。
3. 将 innodb_open_files 的值设置为一个比当前总表数量更大、并留有一定余量的数字，如果现在有15000个表,可以设置为20000。
4. 保存配置后，安排一次计划内的数据库重启,使新配置生效。

在重启之前，我们还仔细评估了服务器系统的文件打开数限制（使用 ulimit -n 命令查看），确保操作系统的限制也高于我们为MySQL设置的新值，避免出现“天花板”问题。

那次重启进行得很顺利，重启完成后，错误日志里那条烦人的警告再也没有出现，数据库的性能也恢复了正常，后来我们复盘，这个问题的根源在于早期规划不足，业务飞速发展创建了大量表，但数据库参数还保持着默认或较小的初始值,最终导致了瓶颈。

通过这次远程处理，我深刻体会到，对于表数量非常多的MySQL实例，提前合理设置 innodb_open_files 和 open_files_limit 参数是多么重要，不能等到报警了才去补救,这已经成了我们巡检数据库时的一个必查项。