MySQL memory_summary_global_by_event_name 怎样看当前内存占用

排查 MySQL 内存上涨时，我更愿意先看 Performance Schema 的“当前还没释放多少”，再看“历史上最高到过多少”。memory_summary_global_by_event_name 正好把这两类信息按内存事件名汇总起来，但字段很多，最容易把累计分配量当成当前占用。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/performance-schema-memory-summary-tables.html

memory_summary_global_by_event_name 到底统计了什么

这张表的粒度是 EVENT_NAME：每一行代表一种内存 instrument，例如某个 SQL、存储引擎或内部模块的内存事件。它回答的是“按事件分类，内存分配行为留下了什么统计”，不是操作系统进程的完整 RSS 报表。

先把最重要的字段分成三组：累计变化看分配和释放次数及字节数；当前状态看还没释放的块和字节；历史水位看采集以来曾经到过的峰值。读表时先按事件名排序，再决定是找当前占用还是找增长来源。

-- 先按当前占用排序，定位仍有较多未释放字节的事件
SELECT
    EVENT_NAME,
    COUNT_ALLOC,
    COUNT_FREE,
    CURRENT_COUNT_USED,
    CURRENT_NUMBER_OF_BYTES_USED,
    HIGH_NUMBER_OF_BYTES_USED
FROM performance_schema.memory_summary_global_by_event_name
ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC
LIMIT 20;

这里的 COUNT_ALLOC 和 COUNT_FREE 是累计次数，CURRENT_COUNT_USED 通常可理解为尚未释放的块数。真正要回答“当前内存占用”，优先读 CURRENT_NUMBER_OF_BYTES_USED，不要直接读 SUM_NUMBER_OF_BYTES_ALLOC。

当前占用、累计分配和高水位要怎样区分

假设某个事件的 SUM_NUMBER_OF_BYTES_ALLOC 很大，这只能说明它在观察期内分配过很多字节；如果同时释放了大部分内存，当前占用可能并不高。相反，当前值不高但高水位很高，说明它曾经出现过突发峰值。

-- 同时查看累计、当前与峰值，避免只凭一个字段下结论
SELECT
    EVENT_NAME,
    SUM_NUMBER_OF_BYTES_ALLOC,
    SUM_NUMBER_OF_BYTES_FREE,
    CURRENT_NUMBER_OF_BYTES_USED,
    HIGH_NUMBER_OF_BYTES_USED,
    (SUM_NUMBER_OF_BYTES_ALLOC - SUM_NUMBER_OF_BYTES_FREE)
        AS calculated_current_bytes
FROM performance_schema.memory_summary_global_by_event_name
WHERE CURRENT_NUMBER_OF_BYTES_USED > 0
ORDER BY HIGH_NUMBER_OF_BYTES_USED DESC;

calculated_current_bytes 用来帮助读者看懂字段关系，不建议把它当成跨版本的唯一诊断口径。实际判断时要同时看事件名、当前值、峰值和采集窗口；不同事件的生命周期不同，不能把所有行简单相加后就声称等于进程 RSS。

我的经验是把结论写成两句：一是“哪个事件现在还占着最多”，二是“哪个事件历史峰值最高”。前一句更接近泄漏或滞留排查，后一句更接近突发流量、批处理或峰值容量评估。

只看当前值时，查询条件怎样写更稳

如果目标是快速找出仍有占用的事件，可以过滤当前字节数，再把高水位放到第二排序键。这样不会让已经回落到零的历史峰值事件挡住当前问题。

-- 只保留当前仍有字节占用的事件，再用高水位辅助排序
SELECT
    EVENT_NAME,
    CURRENT_NUMBER_OF_BYTES_USED AS current_bytes,
    HIGH_NUMBER_OF_BYTES_USED AS peak_bytes,
    COUNT_ALLOC,
    COUNT_FREE
FROM performance_schema.memory_summary_global_by_event_name
WHERE CURRENT_NUMBER_OF_BYTES_USED > 0
ORDER BY current_bytes DESC, peak_bytes DESC, EVENT_NAME ASC;

如果问题是“最近一段业务动作是否带来增长”，可以在动作前记录一次结果，动作后再次查询，用两次快照相减。Performance Schema 的汇总表提供的是累计状态，不会自动替你划分业务请求边界，所以观察窗口需要由排障者自己定义。

TRUNCATE 之后怎样重新建立观察基线

当历史累计值已经很大，排查一个新问题时可以把内存汇总表当作新的观察起点。官方文档说明，对这类汇总表执行 TRUNCATE TABLE 会重置统计基线；它不会释放服务器内存，也不会把真实资源状态变成“已经清理”。

-- 只重置 Performance Schema 的内存统计基线
TRUNCATE TABLE performance_schema.memory_summary_global_by_event_name;

-- 从新基线开始读取当前占用与新的高水位
SELECT
    EVENT_NAME,
    CURRENT_NUMBER_OF_BYTES_USED,
    HIGH_NUMBER_OF_BYTES_USED
FROM performance_schema.memory_summary_global_by_event_name
WHERE CURRENT_NUMBER_OF_BYTES_USED > 0
ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC;

这一步的正确理解是“把计数器和水位的参照点往前推”，不是“释放一块内存”。因此，执行前要记录排障时间点；执行后再做固定时长或固定业务动作的采集，结果才有可比性。

上线前用这张清单判断结果

• 看“现在占用”时是否使用 CURRENT_NUMBER_OF_BYTES_USED，而不是累计分配列。
• 看“曾经峰值”时是否单独读取 HIGH_NUMBER_OF_BYTES_USED，没有把它当成实时值。
• 是否保留了 EVENT_NAME，避免只看总数字却不知道是哪类 instrument。
• 是否把采集窗口写进记录，尤其是在执行过 TRUNCATE 之后。
• 是否区分 Performance Schema 统计、MySQL 进程内存和操作系统 RSS 三种口径。
• 是否有权限读取目标表，并确认相关 memory instruments 已被采集。

一句话总结：memory_summary_global_by_event_name 更像一块按事件分类的内存观测面板。当前值回答“还占多少”，累计值回答“发生过多少分配和释放”，高水位回答“曾经冲到哪里”；把三者分开，排查结论才不会被一个大数字带偏。

相关问题

SUM_NUMBER_OF_BYTES_ALLOC 很大是不是内存泄漏？

不一定。它是累计分配字节数，必须结合 SUM_NUMBER_OF_BYTES_FREE 和 CURRENT_NUMBER_OF_BYTES_USED 判断当前是否仍有大量未释放内存。

TRUNCATE 汇总表后，MySQL 内存会立刻下降吗？

不会。TRUNCATE 重置的是 Performance Schema 的统计基线，不等价于释放服务进程已经持有的内存。

为什么 Performance Schema 数字和 top 看到的 RSS 不一样？

两者统计口径不同：前者按已启用的内存 instrument 汇总，后者反映进程或操作系统层面的内存视图，不能直接要求数值相等。