=========================================================================================================================
#启用收集内存指标
UPDATE setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'memory/%';
#查看运行sys schema里面内存分配的报告
select event_name,current_alloc,high_alloc from sys.memory_global_by_current_bytes where current_count > 0;
#获得每个事件更高级别活动的总体报告
select substring_index(substring_index(event_name,'/',2),'/',-1) as event_type,
round(sum(current_number_of_bytes_used) / 1024/1024, 2) as MB_CURRENTLY_USED
from performance_schema.memory_summary_global_by_event_name
group by event_type
having
mb_currently_used >0
=========================================================================================================================
现在我们可以检查MySQL内部的东西来寻找潜在的MySQL内存泄漏情况:
MySQL在很多地方分配内存，尤其：
-
表缓存
-
Performance_schema(运行:show engine performance_schema status 然后看最后一行)，这可能在系统RAM比较少(1G或更少)时的可能原因。
-
InnoDB(运行show engine innodb status 检查 buffer pool部分,为buffer pool及相关缓存分配的内存)
-
内存中的临时表(查看所有内存表:select * from information_schema.tables where engine='MEMORY')
-
预处理语句，当他们没有被释放时(通过运行show global status like 'Com_prepare_sql'和show global status like 'Com_dealloc_sql'来检查通过deallocate命令释放的预处理语句)
The good news is: starting with MySQL 5.7 we have memory allocation in performance_schema. Here is how we can use it.
好消息是，从5.7开始我们可以通过performance_schema查看内存的分配情况。下面就展示如何使用它：
-
First, we need to enable collecting memory metrics. Run:
UPDATE setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'memory/%';-
Run the report from sys schema:
select event_name, current_alloc, high_alloc from sys.memory_global_by_current_bytes where current_count > 0;-
Usually this will give you the place in code when memory is allocated. It is usually self-explanatory. In some cases we can search for bugs or we might need to check the MySQL source code.
-
首先，我们需要启用收集内存指标，运行如下语句：
UPDATE setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'memory/%';-
运行sys schema里面的报告
select event_name,current_alloc,high_alloc from sys.memory_global_by_current_bytes where current_count > 0;-
通常，这将在分配内存时为你提供代码，它通常是不言自明的。在某些情况下，我们可以搜索错误，或者我们可能需要检查MySQL源代码。
For example, for the bug where memory was over-allocated in triggers (https://bugs.mysql.com/bug.php?id=86821) the select shows:
例如，有一个过度为触发器分配内存的bug：
https://bugs.mysql.com/bug.php?id=86821
查询的显示如下：
The largest chunk of RAM is usually the buffer pool but ~3G in stored procedures seems to be too high.
分配最大一块内存通常是buffer pool，但是约3G的存储过程似乎有点太高了.
According to the MySQL source code documentation, sp_head represents one instance of a stored program which might be of any type (stored procedure, function, trigger, event). In the above case we have a potential memory leak.
根据MySQL source code documentation,sp_head表示存储程序里面的一个实例(比如存储过程、函数、触发器，及事件)。在上面的例子，我们有潜在的内存泄漏的风险。
In addition we can get a total report for each higher level event if we want to see from the birds eye what is eating memory:
另外，我们想要鸟瞰什么吃掉了内存，我们可以获得每个事件更高级别活动的总体报告。