MySQL的VIRT/VSZ远高于配置值属正常现象，因其通过mmap预留虚拟地址空间但仅提交活跃部分；真正需关注RSS持续上涨、swap增长及OOM日志，结合performance_schema与smaps定位真实内存消耗源。

MySQL的虚拟内存（VIRT/VSZ）远高于配置参数是正常现象，不是泄露，也不代表真实内存压力；真正该盯的是RSS（物理内存占用）和swap增长趋势。

为什么ps或top里看到的VIRT动辄上百GB？

MySQL（尤其用JEMalloc或新版glibc）在启动时会通过mmap预留大块虚拟地址空间，用于后续动态分配——比如innodb_buffer_pool_size设为32G，它可能提前映射64G甚至128G的地址范围，但只实际提交（commit）其中活跃部分。这部分“预留未使用”的空间计入VIRT，但不消耗物理内存、不触发OOM、也不会被swap。

常见误导场景：

• 云厂商镜像默认启用JEMalloc，cat /proc/`pidof mysqld`/maps | wc -l 可能返回上万行mmap区域，每行几MB到几百MB，加起来VIRT轻松破百G
• innodb_buffer_pool_size配置为8589934592（即8G），但ps显示VSZ为105G——这完全合理
• 误把VmPeak（进程生命周期最大虚拟内存）当实时占用：cat /proc/`pidof mysqld`/status | grep VmPeak

怎么确认是不是真有内存泄露？

真正的泄露表现为RSS持续缓慢上涨、无明显业务峰值却触发swap、dmesg -T | grep -i "killed process.*mysqld"出现OOM记录。排查要分层验证：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 查真实物理占用：ps -eo pid,rss,vsz,cmd | grep mysqld，重点关注rss列（单位KB），换算成GB后对比innodb_buffer_pool_size + max_connections * (sort_buffer_size + join_buffer_size)理论上限
• 看buffer pool实际使用率：SELECT ROUND(data_bytes/1024/1024/1024,2) AS used_gb FROM information_schema.innodb_buffer_pool_stats;，若长期低于配置值80%，说明缓存没填满，RSS高大概率来自其他模块
• 检查performance_schema内存大户：SELECT event_name, sys.format_bytes(CURRENT_NUMBER_OF_BYTES_USED) FROM performance_schema.memory_summary_global_by_event_name ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC LIMIT 5;，特别注意memory/group_rpl/...（Group Replication）、memory/temptable/...（临时表）、memory/sql/...（SQL解析器）是否异常偏高

performance_schema开启后RSS突然变高怎么办？

MySQL 5.7+默认开启performance_schema，它本身会吃掉100–300MB基础内存，并随连接数、监控项增多线性增长。这不是泄露，但容易被忽略：

• 确认是否真需要全量监控：SELECT * FROM performance_schema.setup_instruments WHERE ENABLED = 'YES' AND NAME LIKE 'memory/%';
• 关闭非必要内存监控项（如不查连接级内存可关memory/sql/thd）：UPDATE performance_schema.setup_instruments SET ENABLED = 'NO' WHERE NAME LIKE 'memory/sql/%';
• 若确定不用，可在启动时加--performance-schema=OFF，但会丢失所有运行时内存分布数据

哪些情况才真要怀疑泄露？

RSS在业务平稳期仍以每天>100MB速度爬升、SHOW PROCESSLIST里大量Sleep连接但Threads_connected不降、information_schema.PROCESSLIST中Time值极大且状态为Waiting for table metadata lock或preparing——这些才指向连接泄漏、长事务阻塞或UDF/插件未释放资源。

此时别只盯着配置参数，先抓/proc/`pidof mysqld`/smaps里Rss:和Size:差异大的区域，再结合pstack `pidof mysqld`看线程卡在哪——很多“泄露”其实是慢查询把内存占住不放，等它执行完就回落了。