这事儿我见多了。前阵子一个朋友半夜打电话，说他们公司的核心数据库内存飙到 95%，应用直接挂了，用户骂声一片。运维群里炸了锅，有人提议重启，有人怀疑是黑客攻击，还有人准备给老板写事故报告。其实，数据库内存占用高，十有八九不是硬件问题，而是踩了几个常见的坑。今天咱们就掰扯掰扯，怎么用三步排查法把内存瓶颈揪出来，顺便把那些“吃内存不吐骨头”的家伙收拾干净。
第一步，先弄清楚内存到底被谁吃了。很多人一看到内存高就慌了，直接去调参数或加硬件。这就像家里漏水了，不去找水管破在哪儿，反而把水龙头拧得更大。正确的做法是登录数据库，用系统自带的工具查看当前的内存分配。比如 MySQL， 能告诉你缓冲池占了多大， 能看出哪个查询在疯狂吃资源。我曾遇到过一个案例，开发写了个没加索引的联表查询，跑一次就能吃掉 1 GB 内存，结果他跑了十几次，内存直接爆了。所以第一步不是拍脑袋，而是用数据说话，把每个模块的内存占用拉出来晒一晒。
第二步，排查那些“慢性杀手”——比如连接池和缓存配置。很多运维图省事，把数据库的连接池设得特别大，比如最大连接数设成 1000，结果平时只有 200 个连接在跑，剩下的 800 个虽然空闲，但每个连接都占几兆内存，加起来就是好几个 GB。更坑的是，有些缓存配置也是默认值，比如 InnoDB 缓冲池默认占内存的 70%~80%。如果服务器只有 8 GB 内存，缓冲池直接吃掉 6 GB，再加上其他进程，不爆才怪。我有个客户，MySQL 缓冲池设了 12 GB，但实际数据量只有 3 GB，剩下的 9 GB 全浪费了。这种时候就得动手调参数：连接池按实际并发量来设，缓冲池按数据的热度来算，别盲目照搬网上教程。
第三步，也是最容易被忽略的，就是检查那些“潜伏的病毒”——慢查询和死锁。内存飙升往往不是突发性的，而是慢性积累的结果。比如一个慢查询跑了 10 分钟，占着内存不放，后面堆了 100 个查询在排队，内存自然就涨上去。更恶心的是死锁，两个事务互相等资源，谁也不让谁，数据库为了处理它们，会不断尝试回滚和重试，每次操作都占用内存，把内存耗光。我见过最离谱的情况是，一个公司用了 ORM 框架，自动生成的 SQL 里有 ，结果一个表有 200 个字段，每次查询都拉回几兆数据，内存很快就满了。所以第三步，开启慢查询日志，用 分析哪些查询是“内存杀手”，然后优化索引、限制返回量，甚至改代码逻辑。
这三步走下来，大部分内存飙升的问题都能解决。但有些朋友会问：“我按步骤查了，内存还是高，怎么办？”这时候就得考虑硬件瓶颈。比如服务器只有 8 GB 内存，但业务高峰期需要 16 GB，那再怎么调也白搭。不过，这种场景其实很少见，更常见的是调完参数后内存降下来，却在几天后又涨回去。这是因为数据库的内存使用有波动，白天业务高峰期查询多，内存占用高；晚上低峰期内存会慢慢释放。所以别指望一次排查就一劳永逸，得把监控跑起来，设置阈值告警，例如内存超过 80% 就发短信通知，这样才能及时介入。
另外，排查内存问题时别只盯着数据库本身。有时候是操作系统在搞鬼，比如 Linux 的 占了大量内存，但数据库以为是自己吃掉的。我有个朋友，数据库内存告警，查了半天发现是系统缓存占了 60% 的内存，实际数据库只用了 30%。这时用 看内存分配，再用 确认，就能判断是不是系统缓存作祟。如果是，就不必慌，因为系统缓存会在需要时自动释放，不会影响数据库性能。
说到底，数据库内存飙升就像家里电器突然跳闸——大部分时候不是电器坏了，而是你同时开了太多东西。三步排查法就是让你先关掉空调、再拔掉微波炉、检查是不是电线老化。别一上来就换电表，那成本太高。而且，我建议把排查步骤写成文档，下次再遇到问题，直接按步骤来，省得半夜翻朋友圈求助。毕竟，运维不是靠感觉，而是靠流程和数据。
我想起一个经典案例：有个公司，数据库每周五晚上都会内存飙升并挂掉。运维排查了三个月，换了三次服务器，最后发现是一个实习生写的定时任务——全量备份时把整个数据库加载到内存里处理。改了一行代码，问题就解决了。所以，别把简单问题复杂化，从最基础的连接、查询、缓存开始查，大概率就能找到症结。如果你已经用这三步排查了仍未解决，那就看看业务代码里是否有内存泄露，比如频繁创建临时表、用 拉全字段、或者事务没及时提交。这些细节往往才是内存飙升的元凶。
