MySQL性能_schema中HIGH_NUMBER_OF_BYTES_USED数值异常问询

问题现象 #

运行在Ubuntu 20.04 LTS虚拟机上的MySQL 8.0.35-27.1中，performance_schema.memory_summary_by_user_by_event_name表的HIGH_NUMBER_OF_BYTES_USED数值异常，远超服务器100GB物理内存，最高达4TB以上，和官方文档描述、实际内存使用情况不符。而memory_summary_by_thread_by_event_name表数值正常，但存在跨线程共享内存导致当前使用总和不匹配的情况。

可能原因分析 #

1. 共享内存重复统计 #

memory_summary_by_user_by_event_name是按用户+事件名聚合的统计，当多个线程共享同一块内存区域时，每个线程的统计都会计入这块内存的大小，最终聚合时就会重复累加，导致总和远超实际物理内存。比如全局缓存、共享表空间相关的内存结构，会被所有关联线程重复统计。

2. 已分配未实际使用的内存（过度分配） #

MySQL的内存分配器（如jemalloc）可能会预先分配内存块，即使这些内存还未被实际使用，HIGH_NUMBER_OF_BYTES_USED也会统计已分配的内存大小，而非实际使用的字节数。这种情况下，统计值会包含未真正占用物理内存的预分配空间，导致数值虚高。

3. 性能_schema统计逻辑的版本bug #

特定版本（如8.0.35-27.1）的performance_schema可能存在统计逻辑缺陷，在聚合用户维度的内存峰值时，错误累加了历史线程的峰值数据，未正确合并或去重共享内存的统计。这类问题通常是版本特定的，可查看官方bug列表确认是否存在同类问题。

4. 配置间接影响 #

若开启了审计插件、全量内存统计等内存密集型功能，可能扩大performance_schema的统计范围，叠加聚合逻辑问题后出现异常高的峰值统计。另外，performance_schema_memory_instrument若开启过多细粒度内存事件，也可能增加统计误差。

验证建议 #

• 对比不同用户的HIGH_NUMBER_OF_BYTES_USED数据，看是否集中在某个用户的特定事件（如memory/innodb/buffer_pool）上，判断是否为共享内存重复统计。
• 查看information_schema.INNODB_BUFFER_POOL_STATS中的实际缓冲池大小，和performance_schema中对应事件的统计值对比，验证是否存在过度分配或重复统计。
• 临时切换内存分配器为系统默认的malloc，重启MySQL后观察统计值是否恢复正常，排查是否是分配器导致的预分配统计问题。
• 升级到MySQL 8.0的最新小版本，确认是否是版本bug导致的异常。

内容的提问来源于stack exchange，提问作者Trendfischer