如何通过内存监控表分析MySQL SQL语句的实际内存消耗？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1029个文字，预计阅读时间需要5分钟。
markdownSHOW PROFILE 输出中的 Memory 列常被误读为SQL 占用内存，但实际上它是 MySQL 5.7 以前旧 profiler 的粗略估算值。从 MySQL 8.0 开始已被标记为 deprecated，默认禁用。即使开启，也只记录极简的分配事件（如 sort buffer 分配），不包括 join buffer、tmp table 内存、InnoDB 行锁结构开启关闭等。它无法反映执行器在真实压力下的内存行行为。
- 执行
SET profiling = 1后，SHOW PROFILES中的Memory值多数为空或为 0 - 该机制不跟踪内存释放，也不区分堆/栈/临时文件回退路径
- 并发场景下线程间内存统计互相干扰，数据不可靠
真正可用的是 performance_schema.memory_summary_by_thread_by_event_name
MySQL 5.7+ 默认启用 performance_schema，其中 memory_summary_by_thread_by_event_name 是唯一能按线程粒度追踪 SQL 执行期真实内存分配的表。关键在于：必须提前开启对应 instrument，否则全为空。
本文共计1029个文字，预计阅读时间需要5分钟。
markdownSHOW PROFILE 输出中的 Memory 列常被误读为SQL 占用内存，但实际上它是 MySQL 5.7 以前旧 profiler 的粗略估算值。从 MySQL 8.0 开始已被标记为 deprecated，默认禁用。即使开启，也只记录极简的分配事件（如 sort buffer 分配），不包括 join buffer、tmp table 内存、InnoDB 行锁结构开启关闭等。它无法反映执行器在真实压力下的内存行行为。
- 执行
SET profiling = 1后，SHOW PROFILES中的Memory值多数为空或为 0 - 该机制不跟踪内存释放，也不区分堆/栈/临时文件回退路径
- 并发场景下线程间内存统计互相干扰，数据不可靠
真正可用的是 performance_schema.memory_summary_by_thread_by_event_name
MySQL 5.7+ 默认启用 performance_schema，其中 memory_summary_by_thread_by_event_name 是唯一能按线程粒度追踪 SQL 执行期真实内存分配的表。关键在于：必须提前开启对应 instrument，否则全为空。