修改perf%ignore_a_1%rmance_schema
因为公司生产环境使用的阿里云rds，修改参数相对方便，performance_schema默认为0，此次修改为1。修改之后提交参数，数据库会进行重启，建议在业务低峰进行。
打开内存监控
登录MySQL数据库，执行如下SQL，打开内存监控。
update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%';
打开之后验证一下。
select * from performance_schema.setup_instruments where name like 'memory%innodb%' limit 5;
**注意：**该命令是在线打开内存统计，所以只会统计打开后新增的内存对象，打开前的内存对象不会统计，建议您打开后等待一段时间再执行后续步骤，便于找出内存使用高的线程。
查找内存消耗
统计事件消耗内存
select event_name, SUM_NUMBER_OF_BYTES_ALLOCfrom performance_schema.memory_summary_global_by_event_nameorder by SUM_NUMBER_OF_BYTES_ALLOC descLIMIT 10;+---------------------------------------+-------------------------------------+| event_name | SUM_NUMBER_OF_BYTES_ALLOC |+---------------------------------------+-------------------------------------+| memory/sql/Filesort_buffer::sort_keys | 763523904056 || memory/memory/HP_PTRS | 118017336096 || memory/sql/thd::main_mem_root | 114026214600 || memory/mysys/IO_CACHE | 59723548888 || memory/sql/QUICK_RANGE_SELECT::alloc | 14381459680 || memory/sql/test_quick_select | 12859304736 || memory/innodb/mem0mem | 7607681148 || memory/sql/String::value | 1405409537 || memory/sql/TABLE | 1117918354 || memory/innodb/btr0sea | 984013872 |+---------------------------------------+-------------------------------------+
可以看到内存消耗最高的event是Filesort_buffer，根据经验，这个应该是排序有关。
统计线程消耗内存
select thread_id, event_name, SUM_NUMBER_OF_BYTES_ALLOCfrom performance_schema.memory_summary_by_thread_by_event_nameorder by SUM_NUMBER_OF_BYTES_ALLOC desclimit 10;+---------------------+---------------------------------------+-------------------------------------+| thread_id | event_name | SUM_NUMBER_OF_BYTES_ALLOC |+---------------------+---------------------------------------+-------------------------------------+| 105 | memory/memory/HP_PTRS | 69680198792 || 183 | memory/sql/Filesort_buffer::sort_keys | 49210098808 || 154 | memory/sql/Filesort_buffer::sort_keys | 43304339072 || 217 | memory/sql/Filesort_buffer::sort_keys | 37752275360 || 2773 | memory/sql/Filesort_buffer::sort_keys | 31460644712 || 218 | memory/sql/Filesort_buffer::sort_keys | 31128994280 || 2331 | memory/sql/Filesort_buffer::sort_keys | 28763981248 || 106 | memory/memory/HP_PTRS | 27938197584 || 191 | memory/sql/Filesort_buffer::sort_keys | 27701610224 || 179 | memory/sql/Filesort_buffer::sort_keys | 25624723968 |+---------------------+---------------------------------------+-------------------------------------+
可以看到内存消耗多的线程都跟Filesort_buffer相关。
定位具体SQL
根据前边我们查到的thread_id去日志里查找对应的SQL，阿里云RDS审计日志相对还是比较强大的。我们直接根据thread_id直接检索。
我们在日志里看到大量这样的SQL，扫描行数在几千到几万不等。尽管每次查询的时间不长，通常在几十到几百毫秒之间，但并发请求的数量很大。
以上就是MySQL生产库内存异常增高怎么排查的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/152594.html
微信扫一扫 
支付宝扫一扫 
