前两天，一个朋友半夜给我打电话，说他的 MySQL 数据库突然内存飙到 90%，网站直接挂了。我问他做了什么，他说只加了个索引。这事听着很熟，MySQL 内存占用高几乎是每个 DBA 和运维人员都踩过的坑。很多人一看到内存飙升，第一反应就是加内存条，或者重启数据库——但问题往往没解决，过两天又会出现。
其实 MySQL 本身是个很“贪吃”的程序，它会尽量把能塞进内存的数据都塞进去，因为内存读写比硬盘快几个数量级。但如果配置不当，或者业务逻辑有缺陷，它就会变成一个无底洞。最常见的元凶之一是 InnoDB Buffer Pool，这个家伙默认情况下会吃掉服务器物理内存的 70% 到 80%。你得知道，InnoDB 缓存的是数据页和索引页，如果表太大、索引太多，或者查询频繁全表扫描，这个池子就会越撑越大。
再往下挖，连接数也是个隐形杀手。每建立一个连接，MySQL 都要为它分配一块内存，用于排序、临时表、结果集缓存等。如果一个连接执行大查询，比如 上亿行的表，它可能会在内存里生成几百 MB 的临时结果。如果同时有几百个连接这么干，内存瞬间就被榨干了。我见过一个案例，某电商平台秒杀活动时，连接数飙到 800，每个连接都带着大排序，结果内存直接爆掉，数据库崩溃。
还有个容易被忽略的点，就是表缓存和元数据锁。MySQL 会把打开的表结构信息缓存在内存里，如果表数量多，比如几千张表，这部分内存消耗也不小。更隐蔽的是，某些 ORM 框架或老旧代码会频繁创建和销毁连接，导致表缓存反复刷新，内存碎片化严重。有一个客户，他的系统跑着跑着内存就涨，查了半天才发现是某个定时任务每秒都执行一次 ，把表缓存撑爆了。
存储引擎层面，MyISAM 和 InnoDB 的内存管理差异很大。MyISAM 只缓存索引，不缓存数据，内存占用看起来低，但查询性能也受限。InnoDB 则把数据、索引、undo 日志、redo 日志甚至自适应哈希索引都往内存里塞。如果你使用分区表，每个分区都会有自己的内存结构，分区数一多，内存开销会成倍增长。一个游戏公司把用户表分成 512 个分区，结果每个分区都要维护独立的缓存，内存占用直接翻了三倍。
“内存泄露”这个说法在 MySQL 里并不完全准确，但有些场景确实像泄露。比如，大事务长时间不提交，undo 日志会一直保留在内存里，直到事务结束。如果一个事务跑了两个小时没提交，可能占用几个 GB 的 undo 内存。还有，存储过程或函数里用了游标却忘记关闭，也会导致内存持续增长。更离谱的是，某些版本的 MySQL 在解析复杂 SQL 时，解析树会留在内存里不释放，需要重启才能清掉。
监控和诊断是解决问题的第一步。你可以用 查看 Buffer Pool 的使用情况，用 performanceschema 追踪内存分配来源。重点关注两个指标： 和 ，如果脏页比例太高，说明写入压力大，内存回收慢。另外，在 processlist 中查看 Sleep 连接的数量，很多都是僵尸连接，占着内存不干活。
优化方向其实就几个：把 Buffer Pool 调小到合理值，比如物理内存的 50% 到 60%，但别低于 20%，否则性能会崩。限制最大连接数，例如 ，同时使用连接池复用连接。对大查询做限流，比如用 让慢查询自动超时。表结构上，删除无用的索引，合并小表，减少分区数。还可以开启 ，让内存分配更平滑。
想说，内存占用高不一定是坏事，说明 MySQL 在努力用缓存加速查询。真正可怕的是内存占用忽高忽低，或者持续增长不回落。如果遇到这种情况，别急着加内存，先检查代码和配置。有一次我帮一个电商网站排查，发现他们有个定时任务每小时全量更新一次缓存，每次更新时内存飙到 95%，更新完又降到 50%。这种波动比长期高占用更伤磁盘。改成增量更新后，内存就稳了。
所以，别把 MySQL 当成黑盒子，它所有的内存行为都有迹可循。理解它的贪婪，管好它的胃口，你才能睡个安稳觉。下次再遇到半夜报警，别慌，先看看是不是哪个同事又跑了个没加条件的 。
