MySQL内存排查：memory_global_total与mysqld实际内存差异问题

1. 补全Performance Schema未统计的内存项 #

MySQL的Performance Schema不会统计所有内存分配，重点检查以下项：

• 二进制日志缓存：每个会话的binlog_cache_size默认32KB，高并发下累积量不可忽视。执行：

  SHOW VARIABLES LIKE 'binlog_cache_size';
  

  结合实际活跃连接数估算总占用：单会话缓存大小 × 活跃连接数。
• 线程栈内存：每个连接的thread_stack默认1MB左右，执行：

  SHOW VARIABLES LIKE 'thread_stack';
  

  总占用为：单线程栈大小 × max_connections。
• InnoDB隐性开销：自适应哈希索引、锁结构、事务字典等不会计入innodb_buffer_pool_size，可临时关闭自适应哈希索引验证：

  SET GLOBAL innodb_adaptive_hash_index = OFF;
  

  观察内存占用是否下降。
• 进程级内存映射：用pmap -x <mysqld_pid>查看进程内存映射，重点看匿名映射（anon）和大内存块，这些可能是未被统计的内存分配。

2. 修正内存统计的认知偏差 #

• ps命令的字段误区：ps -eo size,...显示的是虚拟内存（VSS），不是实际物理内存。改用以下命令看实际驻留内存（RSS）：

  ps -eo rss,pid,user,command --sort -rss
  

  对比x$memory_global_total的结果，缩小差异范围。
• 容器内存的真实统计：用docker stats <容器ID/名称>查看容器的实际内存占用，确认是否真的逼近4GB限制，避免被cgroup统计误差误导。

3. 排查临时表与内核内存开销 #

• 磁盘临时表的残留内存：若业务高峰大量生成磁盘临时表，部分内存可能未及时释放。执行：

  SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';
  

  结合慢查询日志分析大查询的排序、分组操作。
• 内核内存挤占：Docker的内存限制包含内核内存，内核栈、slab分配器等占用过高会触发OOM。查看容器内存明细：

  cat /sys/fs/cgroup/memory/<容器cgroup路径>/memory.stat
  

  重点关注kernel_stack、slab字段的数值。

4. 版本bug排查 #

检查当前MySQL版本是否存在已知内存泄漏bug，优先升级到对应分支的最新稳定版本测试，比如5.7.40+、8.0.30+等版本修复了不少内存泄漏问题。

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