MySQL 8.0.26 InnoDB内存占用过高排查及根因修复技术问询

针对你遇到的MySQL 8.0.26内存占用超出预期、Open tables数量持续增长的问题，我来梳理下排查和修复的核心思路：

一、Open Tables增长与内存占用的关联 #

首先明确：Open tables数量持续增长确实会导致内存占用上升。MySQL会缓存打开的表元数据（表结构、索引信息等），每个打开的表都会占用一定内存空间；而你设置了wait_timeout=31536000（一年），空闲连接不会被自动关闭，每个连接打开的表会一直被缓存，不会释放，最终导致Open tables和内存占用同步上涨。

不过结合你的环境来看：数据库仅5GB、不足25张表，正常情况下Open tables不该持续增长，核心问题出在连接长期不释放+表缓存无限制堆积。

二、根因修复步骤 #

1. 调整连接超时与表缓存参数 #

这是最直接的修复手段：

• 降低连接超时时间：把wait_timeout和interactive_timeout从一年调整为合理值（比如3600秒，即1小时），让空闲连接自动关闭，释放对应的表缓存。修改my.cnf后重启生效，也可以先动态调整验证：

  SET GLOBAL wait_timeout = 3600;
  SET GLOBAL interactive_timeout = 3600;
  

• 配置表缓存上限：添加table_open_cache和table_definition_cache参数，限制表缓存的最大数量，避免无限制增长。建议根据你的max_connections=512来设置，比如：

  [mysqld]
  table_open_cache = 4096
  table_definition_cache = 4096
  

  这个数值可以根据后续监控调整，确保既能覆盖业务需求，又不会过度占用内存。

2. 优化InnoDB自适应哈希索引（AHI）内存占用 #

从你提供的SHOW ENGINE INNODB STATUS结果来看，自适应哈希索引的Hash table占用了不少内存（多个4425293大小的哈希表）。如果你的业务查询不需要频繁依赖哈希索引，可以考虑：

• 临时关闭AHI验证内存变化：

  SET GLOBAL innodb_adaptive_hash_index = OFF;
  

• 如果需要保留AHI，可调整innodb_adaptive_hash_index_parts参数拆分哈希表，降低单个表的内存占用（比如设为64）。

3. 降低InnoDB缓冲池大小 #

你的数据库仅5GB，但innodb_buffer_pool_size设为16G，从监控看缓冲池使用率不足一半（Free buffers占比接近46%）。可以适当调小缓冲池（比如设为8G），节省内存给服务器上的其他应用：

[mysqld]
innodb_buffer_pool_size = 8G

4. 排查会话级内存消耗 #

每个MySQL连接会占用sort_buffer_size、join_buffer_size等会话级内存，虽然默认值不大，但如果存在大量长期存活的连接，累计起来也会占用内存。可以通过SHOW PROCESSLIST查看当前连接状态，确认是否有大量空闲的sleep连接（这也是超时时间设太长导致的）。

三、关于重启验证思路的可行性 #

你的思路完全可行！重启MySQL可以快速释放其占用的所有内存，借此可以明确问题方向：

• 如果重启后内存和Open tables再次持续增长，说明是配置（比如超时时间、表缓存）或应用侧（比如连接不释放、频繁打开新表）的问题，需要针对性调整；
• 如果重启后内存稳定，说明之前是临时的内存堆积（比如某次大查询导致的缓存膨胀），后续监控即可。

重启前建议备份当前状态（比如SHOW GLOBAL STATUS;、SHOW VARIABLES LIKE '%cache%';），方便对比重启前后的变化。

四、补充监控建议 #

后续可以重点监控以下指标：

• Open_tables和Opened_tables：如果Opened_tables持续增长，说明table_open_cache设置过小，需要适当调高；
• Threads_connected：监控连接数变化，确认超时时间调整后空闲连接是否正常关闭；
• 缓冲池使用率：确保innodb_buffer_pool_size设置合理，避免内存浪费。

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