告别内存OOM，解决MySQL内存增长问题
内容提要
本文分析了MySQL内存增长问题，介绍了使用jeprof工具定位内存问题的过程。通过performance_schema和jeprof的使用，发现内存异常增长是由于vector的错误使用导致的。文章提醒注意编译jemalloc时的参数配置，指出jeprof无法捕获buffer pool的内存分配。华为云数据库对该问题进行了修复。
延伸解读
Performance Schema 的监控盲区
Performance Schema 只能监控通过 MySQL 内存分配接口分配的内存，无法覆盖直接使用 malloc 或 new 分配的内存。本文案例中，大事务导致的内存增长并未被自带监控捕获，说明仅依赖 Performance Schema 可能遗漏关键内存问题。读者在排查内存异常时，需意识到这一局限，必要时结合其他工具如 jeprof 进行补充分析。
jeprof 工具的使用门槛与配置要点
使用 jeprof 需将默认的 ptmalloc 替换为 jemalloc，并正确编译和配置。编译时需在 autogen.sh 和 configure 阶段均加上 --enable-prof 选项，否则可能无法生成 profiling 文件。此外，MALLOC_CONF 中的 lg_prof_interval 参数设置过小会严重影响性能，甚至导致问题难以复现。这些细节要求使用者具备一定的调试经验。
vector 动态扩容的潜在风险
write_set 使用 vector 存储大量 push_back 数据，由于 vector 在空间不足时按 2 倍扩容，导致内存占用过高，并伴随频繁的内存申请和释放，影响性能。本文案例中，大事务下 vector 内存无限增长最终引发 OOM。对于大量插入场景，list 可能是更合适的选择，但需结合具体场景评估。
jeprof 无法捕获 buffer pool 内存
jeprof 通过 jemalloc 的采样点捕获 malloc 和 free 调用，而 MySQL 的 buffer pool 内存直接通过 mmap 系统调用分配，不经过 jemalloc，因此无法被 jeprof 监控。读者在分析内存问题时，需区分不同内存分配路径，避免误判。对于 buffer pool 相关内存，需采用其他监控手段。
Q&A
MySQL内存增长的主要原因是什么？
MySQL内存增长主要是由于大事务导致的内存异常增长，特别是使用vector时的错误使用。
如何使用jeprof工具定位MySQL的内存问题？
使用jeprof工具需要将ptmalloc替换为jemalloc，并配置相关参数，然后通过jeprof进行内存采样。
Performance Schema在监控MySQL内存时有哪些局限性？
Performance Schema只能监控通过MySQL内存分配接口分配的内存，无法监控直接使用malloc或new分配的内存。
在编译jemalloc时需要注意哪些参数？
编译jemalloc时需确保加上--enable-prof选项，并注意MALLOC_CONF参数的设置，避免影响mysqld性能。
为什么建议在大事务场景中使用list而不是vector？
因为vector在大量push_back时会导致内存过多占用和性能问题，而list在这种场景下更优。
华为云数据库如何解决MySQL内存增长问题？
华为云数据库对该问题进行了修复，确保在产品中避免内存异常增长的情况。
