MySQL内存使用排查

　　MySQL使用内存上升90%！在运维过程中50%的几率，会碰到这样的问题。算是比较普遍的现象。

　　MySQL内存使用率过高，有诸多原因。普遍原因是使用不当，还有MySQL本身缺陷导致的。到底是哪方面的问题，那就需要一个一个进行排查。

　　下面介绍排查思路： 1.参数配置需要确认，内存是否设置合理

　　MySQL内存分为全局和线程级：

　　备注：query_cache_size 8.0版本已经废弃掉了。 2.存储过程&函数&触发器&视图

　　目前积累的使用经验中，存储过程&函数&触发器&视图 在MySQL场景下是不适合的。性能不好，又容易发现内存不释放的问题，所以建议尽量避免。 MySQL 5.7 MySQL 8.0 3.系统库统计查询

　　备注：有必要统计用户级别内存，因为很多环境对接了第三方插件，模拟从库，这些插件容易内存不释放。

　　备注：找到对应问题事件或线程后，可以进行排查，解决内存高的问题。 4.系统工具查看内存 1）top命令

　　显示系统中各个进程的资源占用状况。

　　2）free命令

　　free-h 命令显示系统内存的使用情况，包括物理内存、交换内存(swap)和内核缓冲区内存。 3）ps命令

　　MySQL相关进程使用内存情况。 4）pmap 命令

　　pmap是Linux调试及运维一个很好的工具，查看进程的内存映像信息。 用法1：执行一段时间记录数据变化，最少20个记录，下面22837是MySQL pid 用法2：linux 命令pmap MySQL pid导出内存，下面22837是MySQL pid

　　RSS就是这个process实际占用的物理内存。

　　Dirty: 脏页的字节数（包括共享和私有的）。

　　Mapping: 占用内存的文件、或[anon]（分配的内存）、或[stack]（堆栈）。

　　writeable/private：进程所占用的私有地址空间大小，也就是该进程实际使用的内存大小。

　　1.首先使用/top/free/ps在系统级确定是否有内存泄露。如有，可以从top输出确定哪一个process。

　　2.pmap工具是能帮助确定process是否有memory leak。确定memory leak的原则：writeable/private (‘pmap –d’输出）如果在做重复的操作过程中一直保持稳定增长，那么一定有内存泄露。 总结

　　对于MySQL内存泄露来说:

　　以上排查里都没有找到原因，可以换下服务器或主从切换观察。也可以进行版本升级（代价不小）。

　　如能提供一个实际环境，也可以一步一步进行调试，抓取内存变化，确定是什么导致内存泄露的问题。之后提交bug，让官方提供修复。

　　墨天轮原文链接：https://www.modb.pro/db/86827