mysql如何查看每个线程的内存消耗_performance_schema应用

MySQL线程内存消耗排查实战：从开启监控到定位元凶

排查MySQL线程内存消耗，就像给数据库做一次深度体检，performance_schema就是那台最精密的CT机。但机器没通电，一切都是空谈。所以，第一步永远是确认这台“CT机”是否已经准备就绪。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

确认 Performance Schema 是否已启用

如果performance_schema功能没有开启，后续所有关于线程内存的查询都只会返回一片空白。验证方法很简单，执行一句SELECT @@performance_schema;，返回值必须是1。如果不是，就需要在MySQL配置文件（如my.cnf）中设置performance_schema = ON并重启服务。对于使用云数据库（RDS）的用户，则需要在控制台的参数设置页面手动开启此选项。

不过，仅仅打开总开关还不够。内存采集的“探头”默认是关闭的，必须手动激活相关的监控项（instruments）：

UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'memory/%';

需要注意的是，这条命令的修改是临时的，MySQL重启后会失效。为了持久化配置，建议在my.cnf文件的[mysqld]段落里直接添加一行：performance-schema-instrument='memory/%=ON'。

查当前活跃线程的实时内存占用

想要最直观地看到谁在消耗内存，sys.memory_by_thread_by_current_bytes视图是最得力的工具。它已经将performance_schema的原始数据进行了聚合和人性化处理，直接查询即可：

SELECT thread_id AS tid, user, current_allocated, current_statement
FROM sys.memory_by_thread_by_current_bytes
WHERE current_allocated > 0
ORDER BY current_allocated DESC
LIMIT 10;

解读这份“体检报告”时，有几个关键点需要把握：

• current_allocated显示的是该线程当前已分配但尚未释放的内存总量（单位是字节），这反映的是实时占用，而非历史峰值。
• current_statement列揭示了线程正在执行或刚刚执行完的语句。如果这里以CALL开头，大概率是存储过程调用，这往往是内存问题的“重灾区”。
• 当user字段为NULL时，说明这是MySQL的内部线程（例如innodb/io、thread/sql/replication），这些后台线程同样可能消耗大量内存。
• 如果查询结果为空，可能的原因有三种：确实没有活跃线程；memory/%监控项未开启；或者对应的线程已经退出。

定位 CALL 存储过程背后的内存大户 SQL

看到CALL my_proc()占用了高内存，先别急着给存储过程判“死刑”。真正的内存消耗者，往往是过程内部某条“低调”的SQL语句，比如创建了隐式临时表、进行了未索引的GROUP BY操作，或者用游标遍历了巨大的结果集。

揪出真凶需要两步走：

第一步，追溯历史语句。从events_statements_history_long表中，找出可疑线程最近执行过的语句摘要：

SELECT THREAD_ID, DIGEST_TEXT, CURRENT_SCHEMA, SUM_TIMER_WAIT, SUM_NUMBER_OF_BYTES_ALLOC
FROM performance_schema.events_statements_history_long
WHERE THREAD_ID = ? -- 替换为上一步查到的 tid
  AND SUM_NUMBER_OF_BYTES_ALLOC > 0
ORDER BY EVENT_ID DESC
LIMIT 20;

第二步，确认线程身份。结合threads表，核实该线程对应的客户端连接信息：

SELECT PROCESSLIST_ID, PROCESSLIST_USER, PROCESSLIST_HOST, PROCESSLIST_INFO
FROM performance_schema.threads
WHERE THREAD_ID = ?;

这个过程有几个常见的“坑”需要注意：

• DIGEST_TEXT会对语句进行归一化处理，例如SELECT * FROM t WHERE id = 1和id = 2会被合并为同一个摘要，因此无法直接看出是哪次调用参数引发了异常。
• 隐式临时表操作不会单独出现在DIGEST_TEXT中，但其导致的内存分配会体现在SUM_NUMBER_OF_BYTES_ALLOC字段的突增上，或者通过sys.io_by_thread_by_bytes视图观察I/O变化来间接判断。
• 如果存储过程中使用了游标配合FETCH循环，每次FETCH都可能触发新的内存分配。但历史表通常只保留最近几十条记录，很容易漏掉早期的、累计消耗巨大的操作。

区分全局内存 vs 线程独占内存

MySQL的内存世界分为两大阵营：全局共享内存（如innodb_buffer_pool_size）和每个连接线程的私有内存（如sort_buffer_size）。排查线程内存问题时，千万别把缓冲池这类全局开销误判为某个线程的“独占资源”。

如何区分？可以这样验证：

• 查看SHOW VARIABLES LIKE '%buffer_pool%';和SHOW STATUS LIKE 'Innodb_buffer_pool_bytes_%';，这些指标反映的是全局状态，与具体线程ID无关。
• 线程级缓冲（如sort_buffer_size、join_buffer_size）是按需分配、用完即释的。但如果执行的语句非常复杂或处理的数据量巨大，单次分配就可能达到几MB甚至上百MB。
• sys.memory_by_thread_by_current_bytes统计的是实际通过malloc分配的内存，这比配置文件中的变量设置值更真实。例如，即便sort_buffer_size设置为2M，但某次排序只用了300KB，那么这里显示的就是300KB左右。

真正棘手的是那些“只借不还”的内存泄漏式场景：比如长期未关闭的游标、没有显式执行DROP TEMPORARY TABLE的临时表，或者在存储过程中反复PREPARE/EXECUTE却忘了DEALLOCATE的动态语句。这些问题不会立刻导致错误，但会让current_allocated像沙漏里的沙子一样缓慢而持续地堆积，最终可能引发内存耗尽（OOM）的严重后果。