检查MySQL内存使用状况

=========================================================================================================================

#启用收集内存指标
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在不少地方分配内存，尤为：

1. 表缓存

2. Performance_schema(运行:show engine performance_schema status 而后看最后一行)，这可能在系统RAM比较少(1G或更少)时的可能缘由。

3. InnoDB(运行show engine innodb status 检查 buffer pool部分,为buffer pool及相关缓存分配的内存)

4. 内存中的临时表(查看全部内存表:select * from information_schema.tables where engine='MEMORY')

5. 预处理语句，当他们没有被释放时(经过运行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:另外，咱们想要鸟瞰什么吃掉了内存，咱们能够得到每一个事件更高级别活动的整体报告。