案例 23：MySQL 字符集转换
4.7 MySQL 字符集转换 发现程序退出时几乎没有内存未释放，也不存在潜在的内存泄漏。三次测试过后，发现结果是一致的。这 是什么原因？ “ 大家都知道 MySQL 的 performance schema 用于监控 MySQL server 在一个较低级别的运行过程中 的资源消耗、资源等待等情况，但它为什么可能会导致内存泄漏呢，看来关于 ps 还有不少待挖掘的宝藏 哦~ ” 总结
- 注意 MySQL 自身的内存规划，为保证 MySQL 的性能，innodb buffer pool 大小设置要合理，可以根 据实例读写负载的情况适当调整 buffer pool 的大小。并且 innodb buffer 与连接会话内存的总和尽量 不要超过系统物理内存。
- 调整 oom_score_adj 参数（/proc/
/oom_score_adj），将 MySQL 被 oom-killer 锁定的优先级降 低。这个参数值越小，越不容易被锁定。 - 加强内存的监控和报警，一旦报警，DBA 应该迅速介入，选择性 Kill 掉一些占用较多内存的连接。
- 在开启 performance_schema 时，会有额外的内存开销，通过 valgrind-memcheck 内存分析工具发现， 较大概率发生内存泄漏。它有可能也会导致 OOM，在场景中若不需要 performance_schema 可以完全 禁用，或需要尽量只开启必要的 instrument。 4.7 MySQL 作者：xuty 一、背景 开发联系我，说开发库上有一张视图查询速度很慢，9000 条数据要查 10s，要求我这边协助排查优化。 二、问题 SQL Server version: 5.7.24-log MySQL Community Server (GPL) 这个 SQL 非常简单，定义如下，其中就引用了 view_dataquality_analysis 这张视图，后面跟了两个 where 条件，并且做了分页。 SELECT * FROM view_dataquality_analysis WHERE modelguid = ‘710adae5-1900-4207-9864-d53ee3a81923’ AND configurationguid = ‘6845d000-cda4-43ea-9fd3-9f9f1f22f95d’ limit 20; 我们先去开发库上运行一下这条 SQL，下图中可以看到确实运行很慢，要 8s 左右。