上周三凌晨两点，我盯着监控面板上那条几乎垂直向上的内存曲线，后背发凉。那台8G内存的MySQL实例，占用率从45%一路飙到97%，用了不到四十分钟。更气人的是，业务量根本没涨，QPS稳如老狗。这不是我第一次被内存问题半夜叫醒，但每次排查都得从头捋一遍。今天干脆把这几年的经验攒成一篇，把MySQL内存飙升最常见的五个根源一次说清楚，下次你遇到，直接照着查。
第一个根源，也是最容易被忽略的——连接数爆炸。很多人以为连接数就是show processlist里那几行，但MySQL每个连接都要分配独立的内存缓冲区，默认是256KB的threadstack加上netbufferlength，还有sortbuffersize、joinbuffersize这些。一个连接轻松吃掉几MB，如果应用层连接池配置不当，或者有慢查询卡住连接不释放，几百个连接堆上去，几个G的内存就没了。我见过最夸张的一次，一个PHP项目用了pconnect，连接池没上限，高峰期堆了800多个连接，光缓冲区就吃了3.2G。排查方法很简单，看Threadsconnected和Threadsrunning这两个状态值，如果前者远大于后者，基本就是连接泄漏或者池子配大了。
第二个根源是InnoDB缓冲池，这个大家熟，但坑在于很多人不知道它和内存飙升的关系。innodbbufferpoolsize设了6G，MySQL启动就会预分配，这部分内存看着高是正常的。但问题是，如果你同时开了多个实例，或者buffer pool里有大量脏页没刷盘，内存占用就会在预分配基础上再往上跳。更隐蔽的是，5.7以后的版本默认开了innodbbufferpoolinstances，分片越多，每个分片的管理结构也吃内存。我见过一个项目，buffer pool设了8G，但实际占用能到9.5G，多出来的部分是自适应哈希索引和锁信息。查这个，看Innodbbufferpoolpagesdirty和Innodbbufferpoolpagestotal的比值，如果脏页比例长期超过75%，说明刷盘跟不上，内存里积压的数据越来越多。
第三个根源很多人想不到——临时表。MySQL执行排序、分组、去重操作时，如果数据量超过tmptablesize和maxheaptablesize（默认都是16M），就会在磁盘上建临时表。但低于这个阈值时，临时表直接建在内存里，用MEMORY引擎。问题在于，如果你把这两个参数调得很大，比如都设成1G，恰好又有复杂的GROUP BY查询，内存临时表一个就能吃掉几百M。我遇到过最狠的案例，一个报表查询，三个大表JOIN加GROUP BY，临时表占了1.8G内存，直接把实例拖垮。查这个，看Createdtmpdisktables和Createdtmptables，如果磁盘临时表很少但内存临时表暴增，那十有八九是这两个参数设太大了。
第四个根源是表缓存和元数据锁。tableopencache控制了MySQL能缓存的表描述符数量，默认2000，但如果你有大量分区表或者频繁执行ALTER TABLE，缓存里会堆积大量表结构信息。每个表描述符大约占用4KB内存，看起来不多，但架不住数量大。更麻烦的是元数据锁，一个长时间运行的事务，哪怕只是开了个事务没提交，它持有的MDL锁会让后续所有对该表的DDL操作排队，同时表缓存只增不减。我见过一个生产环境，业务代码里有个bug，事务开启后忘记提交，结果tableopencache从默认的2000一路涨到8000多，光这一项就吃了32M内存。虽然单看不大，但配合其他因素，就成了压垮骆驼的一根稻草。
第五个根源，也是最容易被甩锅的——查询缓存和预处理语句。MySQL 5.7及之前版本默认开启查询缓存，但这个功能在8.0已经被彻底移除，因为它在大并发下反而拖垮性能。但很多老项目还在用5.7，querycachetype设成DEMAND，结果每个查询都要去检查缓存，缓存碎片和锁竞争导致内存碎片化严重。预处理语句（PREPARE）更隐蔽，它需要为每条语句分配内存保存执行计划，如果业务代码里不断生成新的预处理语句但没释放，内存就会像雪球一样滚大。查这个，看Qcachefreeblocks和Qcachelowmemprunes，如果碎片多且频繁淘汰，说明查询缓存设置不合理。预处理语句则看Preparedstmtcount，如果这个值持续增长不回落，基本就是泄漏了。
排查这些根源，我有个习惯，先看全局状态值，再查配置参数，才看慢查询日志。很多DBA一上来就翻慢查询，其实方向反了。内存飙升往往是配置和连接管理的问题，不是SQL的问题。你先把Threadsconnected、Innodbbufferpoolpagesdirty、Createdtmptables、tableopencache、Preparedstmtcount这五个值拉出来，对照正常基线看哪个异常，基本就能锁定根源。
说句实在话，MySQL内存问题没有一次性能解决的神药。你把这五个根源都摸清了，再结合自己的业务场景，该调连接池，该缩buffer pool，该优化SQL。我上个月帮客户处理的那个案例，发现是连接池最大连接数设了500，但业务峰值也就100多，白白浪费了400个连接的内存空间。改完配置，内存占用直接降了40%，再也没半夜报警过。
