半夜收到监控告警MySQL内存占用一路飙到百分之九十多swap已经被吃了四五个G线上业务开始出现查询变慢、连接超时。排查mysql占用内存过大问题很多同学第一反应是“缓存开太大了”直接把innodb_buffer_pool_size调小结果业务IO起来之后变成另一种故障磁盘打满、慢查询翻倍。这类问题不能靠猜得从内存分配框架入手一步步查清楚内存到底花在哪了。这篇文章算是我整理的一次完整排查复盘围绕MySQL实例内存、物理内存分配、常见内存黑洞和长期优化手段展开。适合正在接手MySQL运维的DBA、后端开发也适合被“内存告警”折磨过几次的运维同学。核心思路只有一条先看内存去哪了再决定要不要调参。1. 排查前的准备先确认现象再动参数1.1 判断是正常占用还是病态占用MySQL本身就是吃内存的应用尤其InnoDB引擎会把大量数据页缓存到内存里目的是减少磁盘IO。一个刚启动、配置了8Ginnodb_buffer_pool_size的实例空闲状态下内存占用冲到6-7G是非常正常的事并不代表“内存泄漏”。真正需要警惕的是三个信号第一内存占用随时间持续上涨重启后回落过几天又涨上去这是典型的“缓慢泄漏”特征。第二内存占用突然暴涨伴随连接数飙升或者大量大查询并发这通常和会话级缓存、临时表、排序有关。第三内存没有涨太多但swap换入换出非常活跃这说明物理内存已经不够用了系统强制回收MySQL的页。所以排查第一步不是看“占用多少”而是看“占用曲线什么形态”。我习惯把内存和连接数、慢查询数量、TPS/QPS放到同一张监控图上看很多时候内存暴涨的前几分钟连接数或者慢查询已经替你指出了方向。1.2 先收集四类基线数据动任何配置之前先记录当前状态。推荐按这个顺序收集数据# 系统层面物理内存、swap、缓存状态 free -h cat /proc/meminfo # 进程层面RSS、共享内存、虚拟内存 ps aux --sort-rss | head -20 top -b -n 1 -o %MEM | head -30 cat /proc/$(pidof mysqld)/status | grep -E VmRSS|VmSwap|VmSize # MySQL内部缓冲池、连接数、临时表、排序内存 mysql -e SHOW GLOBAL STATUS LIKE InnoDB_buffer_pool%; mysql -e SHOW GLOBAL STATUS LIKE Threads_connected; mysql -e SHOW GLOBAL STATUS LIKE Created_tmp_%; mysql -e SHOW GLOBAL STATUS LIKE Sort_merge_passes; # 配置基线关键内存参数当前值 mysql -e SHOW VARIABLES LIKE innodb_buffer_pool_size; mysql -e SHOW VARIABLES LIKE max_connections; mysql -e SHOW VARIABLES LIKE performance_schema;这组数据合起来就是一个内存快照。我踩过几次坑之后发现很多人只拿free -h看系统内存忽略了/proc/{pid}/status里的VmSwap这个值能直接告诉你MySQL有多少内存被挤到swap了。如果VmSwap已经有好几G说明内存压力非常真实不是监控误报。1.3 别被top里的RSS骗了排查内存问题最容易翻车的地方就是对RSS的误读。top里看到的RES包括两部分一部分是进程独占的私有内存另一部分是和别的进程共享的共享内存。MySQL的InnoDB缓冲池默认使用mmap分配大量内存页会被统计为共享页。这意味着单看RES可能高估了MySQL的独占内存但反过来Linux在计算可用内存时会把这部分共享页算进page cache一旦物理内存吃紧这些共享页可以被回收。很多“内存占用过大”误报就是这么来的。所以排查时一定要区分两件事缓冲池占了多少、会话缓存又占了多少。简单粗暴的做法是innodb_buffer_pool_size多大物理内存里就有多大一块“静态占位”这部分基本不会波动波动剧烈的部分是连接线程、排序、临时表、日志缓冲这些“动态内存”。2. 从全局到实例定位内存具体去向2.1 用performance_schema给MySQL做内存审计MySQL 5.7之后performance_schema里提供了内存维度的统计这是排查内存问题最直接的工具。很多同学不知道这个入口还在用strace或者看系统层面走了不少弯路。开启performance_schema后默认5.7就是开启的可以直接按内存占用排序查SELECT event_name, current_alloc, high_alloc, high_number_of_bytes_alloc FROM sys.memory_global_by_current_bytes WHERE current_alloc 0 ORDER BY current_alloc DESC LIMIT 20;这个SQL会把当前内存占用最高的内部模块列出来比如memory/innodb/buf_buf_pool、memory/sql/THD、memory/performance_schema/table_share等。current_alloc是当前分配high_alloc是历史峰值两个值一对比就能看出是持续堆积还是瞬时峰值。实际拦截内存侵占的场景里我见过最典型的案例就是performance_schema自身的内存表把内存吃爆了。performance_schema默认会为每个连接维护大量状态记录连接多、并发高的时候它自己的内存开销可能到好几个G。这时候用上面的SQL查出来排第一的竟然是memory/performance_schema/events_statements_summary_by_thread_by_event_name你会觉得挺魔幻的但确实会发生。2.2 区分全局缓冲区和会话私有内存MySQL的内存可以粗分成两类一类是全局共享的比如InnoDB缓冲池、数据字典缓存、表缓存、日志缓冲另一类是每个连接私有的比如排序缓冲、连接缓冲、随机读缓冲、临时表堆。全局缓冲一般比较稳定会话私有内存则随着并发数和查询模式波动。下面这张表是我常用的归类方式内存类型参数默认值8.0常见主要特征全局共享innodb_buffer_pool_size128M占最大头运行期基本稳定全局共享innodb_log_buffer_size16M事务日志缓冲一般不大全局共享table_open_cache / table_definition_cache2000 / 2000元数据缓存表多时会涨全局共享key_buffer_size8MMyISAM专用InnoDB下可以忽略会话私有sort_buffer_size256K每次排序都会单独分配会话私有join_buffer_size256K关联查询无索引时可能暴涨会话私有tmp_table_size / max_heap_table_size1M / 16M内部临时表上限会话私有read_buffer_size / read_rnd_buffer_size1M / 256K顺序/随机读缓冲这个分类最大的价值是全局缓冲好算每个连接私有缓冲乘上连接数就是理论上限。比如sort_buffer_size设成2M同时有200个连接在做排序光这一项就可能占用400M。MySQL的参数不是设得越大越好尤其是会话级参数设得越大高并发下被放大的倍数越可怕。2.3 连接数是被忽视的内存放大器MySQL每个连接进来至少要分配一个THD对象这个对象包含语句状态、预处理语句、会话变量、临时表结构等单看一个没多少几十上百个堆起来就很吓人。Threads_connected一高内存就跟着涨这是最常见的内存“放大器”。快速验证连接数和内存关系的方法SHOW GLOBAL STATUS LIKE Threads_connected; SHOW GLOBAL STATUS LIKE Max_used_connections; SELECT thd_id, processlist_id, current_allocated FROM sys.session ORDER BY current_allocated DESC LIMIT 10;sys.session这个视图能直接看到每个连接占了多少内存配合processlist里的Command和State能定位到具体是哪类会话在吃内存。比如某个应用连接池配置失误建了几百个空闲连接每个连接还执行过SET SESSION sort_buffer_size64M那内存直接失控。3. 常见根因与针对性优化实操3.1 参数配置型缓冲池和日志缓冲怎么调才合理innodb_buffer_pool_size是MySQL内存占用的大头也是最容易背锅的参数。很多教程写“设为物理内存的70%”这个说法非常粗糙。我见过一台32G内存的机器上面跑了MySQL和一个Java应用MySQL缓冲池设了24G还没到业务高峰机器就swap了。合理的算法应该是物理内存减去系统预留一般2-4G减去应用和其他进程的需求再乘以0.7-0.8左右的系数。比如32G物理内存系统预留3GJava应用固定用8G那MySQL能拿到的上限大约21G保险起见缓冲池设16-18G比较合适。设置完观察InnoDB_buffer_pool_read_requests和InnoDB_buffer_pool_reads的比例命中率在99%以上说明缓冲池够用低于95%才值得考虑扩容。innodb_log_buffer_size平时不是内存大户但事务量大时如果这个值设太小MySQL会频繁把日志缓冲刷到磁盘反而增加磁盘IO消耗。这个参数一般16M-64M足够不需要盲目加大它不会像缓冲池那样线性占内存。还有一个容易被忽略的参数innodb_buffer_pool_instances。默认情况下8G以上的缓冲池会自动划分成多个实例如果把它设成1InnoDB内部会退化成单实例管理并发高的时候锁竞争严重CPU先飙升然后内存管理效率也会下降。一般按照缓冲池每4G对应一个instance来设比如16G缓冲池配4个实例。3.2 连接风控型限制连接和释放长期空闲会话连接数过高导致的内存问题优化重点不是调低MySQL的max_connections而是管住应用层的连接池。有些应用框架会自动创建连接但不会及时关闭连接池的maxActive设成了100而实际QPS只需要20等于白白浪费了80个连接的内存。MySQL这边的兜底方案是wait_timeout和interactive_timeout。我通常把wait_timeout设成60-300秒让长时间不用的连接尽快断开。之前排查过一个集群Threads_connected长期维持在2000但真正有查询的只有200多调低wait_timeout后内存占用直接降了2G多。SQL层面的清理SET GLOBAL max_connections 500; SET GLOBAL wait_timeout 300; SET GLOBAL interactive_timeout 300;但这几个参数要结合业务调整有的业务场景是长连接频繁交互wait_timeout设太小会导致连接反复重建反而增加线程切换开销。我一般是观察监控里的“连接创建速率”和“连接崩溃速率”再决定要不要收紧。应用层也要同步排查。Java的HikariCP、Druid或者Python的SQLAlchemy连接池都要设置合理的maximumPoolSize和生命周期。部署在同一个物理机上的多个应用如果各自建了连接池叠加起来比MySQL单点能承受的范围大得多这时候只调MySQL侧是治标不治本。3.3 临时表和排序内存大查询的内存陷阱临时表和排序内存是动态内存波动最大的来源也是很多“MySQL内存无端涨高”的幕后黑手。原理挺直白查询执行中遇到ORDER BY、GROUP BY、DISTINCT、UNION如果内存放不下MySQL会先往内存里放满了再落盘但如果内存配置不合理可能还没到落盘阶段就先卡爆了内存。这类问题的典型特征内存暴涨时间点和慢查询时间点高度重合。我排查过几次每次都是几条没走索引的大查询把内存顶上去的SQL本身一条就能吃几个G内存。核心参数两个tmp_table_size和max_heap_table_size。一个查询生成的内部临时表超过这个上限就会被转换为磁盘临时表。很多人习惯把tmp_table_size调到64M、128M却忘了把max_heap_table_size同步调上去导致实际内存临时表的生效上限还是以max_heap_table_size为准。辅助排查SQLSHOW GLOBAL STATUS LIKE Created_tmp_disk_tables; SHOW GLOBAL STATUS LIKE Created_tmp_tables; SHOW GLOBAL STATUS LIKE Memory_used_tmp_tables; SELECT * FROM sys.schema_tables_with_full_table_scans; SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_ROWS_EXAMINED DESC LIMIT 10;这里要重点看Created_tmp_disk_tables / Created_tmp_tables的比例如果超过50%说明临时表大量落盘磁盘IO会有压力如果比例不高但内存还是猛涨那就要查单条SQL的执行计划看看Using temporary到底是内存临时表还是磁盘临时表。排序方面sort_buffer_size我建议保守配置线上设为2M-4M足够而不是文档上的“建议值”。一次排序操作就得按这个值分配连接多的时候内存翻倍很快。对于特别大的排序正确思路是优化索引让数据预先有序而不是把sort buffer调到无限大。3.4 表缓存和字典缓存表多的实例要注意一个实例上挂着几千张表时table_open_cache和table_definition_cache会默默吃掉不少内存。尤其一些ORM框架会自动建表、读写大量分表每个分表都要在MySQL里占一份缓存。查看表缓存当前状态SHOW GLOBAL STATUS LIKE Open_tables; SHOW GLOBAL STATUS LIKE Opened_tables; SHOW VARIABLES LIKE table_open_cache; SHOW VARIABLES LIKE table_definition_cache;如果Open_tables长期接近或等于table_open_cache说明缓存不够用MySQL会频繁淘汰表缓存Opened_tables就会持续增长。此时可以逐步调大table_open_cache但不要一次性调太高因为它直接影响内存占用。表缓存和连接数是相互影响的每个连接打开的表都会计入table_open_cache的占用。所以一个实例如果连接数很高表缓存的实际占用会成倍增加。这对组合经常让人觉得内存“涨得没道理”。顺手把table_definition_cache也检查一下它的单条记录比表缓存更大存的是表结构定义分表多的业务里面膨胀特别快。3.5 内存碎片与连接线程栈隐藏的慢涨源内存碎片在MySQL里不如在C程序里那么直观但长时间运行后会真实反映出来。MySQL使用自己的内存分配器在高并发、大量临时分配回收的场景下glibc malloc容易出现碎片化表现在监控上就是实例内存缓慢上涨重启后立刻降下来。判断有没有内存碎片的辅助手段是看实例连续运行几天后SHOW ENGINE INNODB STATUS里的BUFFER POOL AND MEMORY段以及performance_schema里的内存分配统计。如果大量内存集中在memory/innodb/mem0mem和memory/mysqld/QuickMalloc里而且数值随着时间只增不减说明碎片问题确实存在。这时候的通用解法是配合5.7的innodb_buffer_pool_load_at_startup和innodb_buffer_pool_dump_at_shutdown在维护窗口计划性重启。但重启不是长期方案根本解法还是要治理SQL、压缩连接数减少短连接和临时内存分配的频率。对于纯内存碎片业内常见手段是调整innodb_use_native_aio或者在my.cnf里用malloc-libjemalloc替换内存分配器这个方案我在强烈高并发场景下实测有效但需要重新编译或加载连接库动之前一定先在测试环境验证。4. 真实环境的隐藏内存黑洞与排查实录4.1 performance_schema自身成了最大内存消耗者第一次遇到这个坑时挺意外。一个8C16G的实例innodb_buffer_pool_size只设了6G结果内存占用一直在12G左右。用memory_global_by_current_bytes一查排第一的竟然是performance_schema/events_statements_history_long占了将近3G。原因是performance_schema里开启的采集项太多历史事件、语句摘要、会话状态全都会在内存里保留。实例上连接多、SQL多样化时这些内存表会持续膨胀。5.7版本里performance_schema默认开启如果不做裁剪它最多能占用实例总内存的10%以上。裁剪思路并不是直接关闭performance_schema而是关掉那些你平时根本不会查的高频采集项UPDATE performance_schema.setup_consumers SET ENABLED NO WHERE NAME IN (events_statements_history_long, events_transactions_history_long, events_stages_history_long); UPDATE performance_schema.setup_consumers SET ENABLED YES WHERE NAME IN (events_statements_history, events_statements_current);events_statements_history_long默认保留1000条完整SQL文本每一条SQL文本、参数都要存内存SQL越长、并发越多内存涨得越快。关掉这个采集项后performance_schema的内存占用能降一半以上还不影响平时抓慢查询和在线会话。这里有个使用心得performance_schema的内存采集是排查内存问题的利器但它本身也是潜在的内存消耗者。上线前先评估实例规格如果内存本来就紧张最开始就不要开events_statements_history_long只在排查期间临时开起来抓数据抓完再关掉。4.2 监控程序和备份脚本叠加造成的“伪内存膨胀”除了MySQL自身同一台机器上如果部署了多个监控采集器、备份代理它们会一起争夺物理内存。排查内存问题时这些“邻居进程”经常干扰判断。我用ps aux --sort-rss扫进程时不止一次看到pt-stalk、mysqldump、xtrabackup挂着几十个G的RSS。先说mysqldump。它是逻辑备份默认拉取全表数据到客户端再转储如果不加--single-transaction配合大缓冲备一个几十G的库备份进程的内存会非常夸张。更稳的姿势是用Xtrabackup这类物理备份或者在做逻辑备份时加上--quick --skip-lock-tables --set-gtid-purgedOFF --net-buffer-length4096减少客户端内存堆积。监控类工具也要注意采样脚本本身的性能。有的同学拿Python写循环抓SHOW GLOBAL STATUS循环里又不做sleep等于变相在MySQL上做高频查询连接数瞬间拉高。系统监控建议用Prometheus mysqld_exporter这类成熟方案采集间隔控制在15秒以上而不是自造轮子。4.3 容器环境中的cgroup限制和不可见内存MySQL跑在Docker容器里时内存排查又多了一层复杂性。容器通过cgroup限制内存free -h看到的是宿主机内存不是容器实际可用内存top里的RES也是宿主机的视角如果容器里没有挂载正确的/proc进程看到的内存信息可能是宿主机全量内存。之前有个现场反馈“MySQL一启动就占用主机70%内存”结果一看容器配置--memory没有加限制而innodb_buffer_pool_size却按宿主机的70%设了。这个属于纯粹的容量规划错误但排查起来很迷惑因为从宿主机看就是MySQL把内存吃完了而实际上MySQL只是用了它能看到的全部内存。正确的容器化部署姿势给容器设置--memory上限数值要小于宿主机可用内存MySQL参数里的innodb_buffer_pool_size按容器上限的60%-70%配置而不是按宿主机同时加上--memory-swap限制避免swap失控在容器外监控时用docker stats或者cgroup目录下的memory.current、memory.max来确认实际占用而不是看free -h。Kubernetes部署同理Pod里配置resources.limits.memory后MySQL的初始化参数要由资源配额推导优先使用$MY_CPU_LIMIT、$MY_MEM_LIMIT这类环境变量来自动计算配置而不是写死一个固定值否则迁移到不同规格节点就会踩雷。4.4 内存不足触发OOM的现场取证内存问题严重到触发Out Of Memory时排查思路要切换到“谁吃了内存谁被杀为什么杀的是MySQL”。Linux的OOM killer会在内存耗尽时按oom_score杀掉进程MySQL这种大内存进程往往首当其冲。排查OOM的第一步是看系统日志dmesg -T | grep -i out of memory journalctl -k --since 1 hour ago | grep -i oom日志里会记录当时各进程的内存占用排名重点看有没有瞬间暴涨的进程。另一个关键数据是/proc/{pid}/oom_score这个值越高进程越容易被杀。MySQL可以通过/proc/{pid}/oom_score_adj调整优先级但不建议无脑调低因为内存真的耗尽时强行保住MySQL会让系统持续hang住反而造成更长时间的业务不可用。我看到过一个奇怪案例MySQL每次在凌晨4点被OOM killer杀掉查日志发现是cron里一个全库统计脚本在凌晨4点执行脚本一跑就把内存打满。调整了脚本的执行时间后问题再也没出现过。这种“规律性OOM”基本都是定时任务造成的排查时多看一眼crontab里的任务往往比耗在数据库参数上更有效。4.5 大事务和长事务对内存的延迟影响最后一个经常被忽略的内存黑洞是长事务。一个事务如果长时间不提交它的undo log、回滚段信息、锁信息都要在内存里保留这期间如果有大量DML内存占用会持续积累。等内存告警时事务已经跑了几个小时人肉定位很难。排查长事务SELECT trx_id, trx_state, trx_started, trx_rows_modified, trx_mysql_thread_id, trx_query FROM information_schema.innodb_trx ORDER BY trx_started ASC;如果发现事务开始时间很早但trx_rows_modified显示修改行数在不断增加说明有个业务逻辑在长时间持有事务一直在写数据而且没有提交。这个状态下内存和undo log都会同步膨胀。治理长事务需要应用层配合事务保持时间要短跨服务的远程调用尽量放到事务外面大批量数据更新要拆批次commit线上如果无法立刻修复应用代码DBA侧可以先杀掉这些长时间事务再用临时监控工具识别产生长事务的SQL来源。5. 排查之后的常态化优化方案5.1 建立内存基线和周巡检SQL内存问题的难处在于它不像CPU那样有明确的“100%就是有问题”的标准MySQL是缓存型应用内存占用高不等于异常。所以我把“建立基线”放在长期方案的第一位一个实例经过充分压测、业务高峰验证后记录下它在空闲态、常态、高峰态的合理内存区间之后监控告警都基于这个基线设置阈值。巡检SQL可以固化成一个只读账号定期执行-- 维度1缓冲池命中率 SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read_requests; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_reads; -- 维度2临时表落盘率 SHOW GLOBAL STATUS LIKE Created_tmp_disk_tables; SHOW GLOBAL STATUS LIKE Created_tmp_tables; -- 维度3连接数水位 SHOW GLOBAL STATUS LIKE Threads_connected; SHOW GLOBAL STATUS LIKE Max_used_connections; -- 维度4排序落盘 SHOW GLOBAL STATUS LIKE Sort_merge_passes; SHOW GLOBAL STATUS LIKE Sort_rows;我习惯每周跑一次把结果存入历史表形成长周期趋势。一旦某个指标和上周同期偏差超过30%就直接定位预警不用等到业务反馈“最近系统很卡”再开始排查。5.2 参数调整的顺序和验证闭环内存优化涉及多个参数时调整顺序是有讲究的。我的建议是先做减法再做加法。所谓减法是先把不需要占内存的东西关掉比如临时采集项、过大的会话缓冲、多余的功能开关加法是确定哪些缓存不够用比如表缓存不足、缓冲池命中率过低再逐步加大。参数调整后验证闭环分三步第一步SHOW VARIABLES确认参数已生效第二步观察24-72小时的performance_schema内存统计和系统内存曲线第三步看业务指标有没有劣化比如连接建立时间变长、慢查询增多、IO延迟变大。没有业务指标配合的参数调整都是盲调。有些参数是动态生效的比如innodb_buffer_pool_size在5.7可以在线修改max_connections也可以直接SET GLOBAL但像performance_schema的采集项和innodb_use_native_aio这类需要重启实例的改动一定要走变更窗口不要上班高峰直接改。5.3 给运维团队的两个实战建议结合我处理过的多个MySQL内存问题给团队的两个建议一个是监控指标不要只盯memory.usage要细分到MySQL内部至少包含innodb_buffer_pool_size、连接数、临时表状态、排序状态否则你只能看到“内存高了”看不到“为什么高”。另一个是排查内存问题前先确认操作系统版本和内核版本。不同版本的glibc内存分配策略差异很大同一个MySQL实例在CentOS 7和CentOS 8上内存表现可能差一个量级。如果MySQL跑在旧内核上频繁出现内存碎片类问题优先考虑升级操作系统或者切换jemalloc而不是反复调整MySQL参数。我个人在实际排查过程中得到的体会是MySQL内存问题九成以上不是单一原因往往是连接数偏高、会话缓冲偏大、临时表配置不合理几个因素叠在一起层层放大。所以排查时不要急着动innodb_buffer_pool_size先把Threads_connected、Created_tmp_disk_tables、sort_merge_passes这些动态指标看一遍很多时候问题根源在SQL层和应用层只是最终都体现在内存上。最后一句话内存监控告警里藏着大量信息先看趋势图再看参数表最后才动配置这个顺序能帮你少走很多弯路。