首先确认 performance_schema 已启用（SELECT @@performance_schema 返回 1），再启用内存仪器（UPDATE setup_instruments SET ENABLED='YES' WHERE NAME LIKE 'memory/%'），确保生效数量超200；接着通过 memory_summary_by_account_by_event_name 定位高内存用户，再关联 threads 和 memory_summary_by_thread_by_event_name 查具体线程与事件，区分真实消耗与 buffer pool 等未监控内存，最终结合 processlist 状态判断是否为游标未关、事务未提交等逻辑问题。
查 performance_schema 是否已启用并配全内存仪器
没开 performance_schema 或没启内存监控，后面所有查询都返回空。先确认基础状态：
- 执行
SELECT @@performance_schema;，结果必须是1 - 运行
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'memory/%';—— 这步不能跳，MySQL 默认只开部分内存仪器，memory/sql/TABLE、memory/temptable/physical_ram等关键项常处于NO - 检查是否生效：
SELECT COUNT(*) FROM performance_schema.setup_instruments WHERE NAME LIKE 'memory/%' AND ENABLED = 'YES';，建议值 > 200；若只有个位数，说明更新没生效或实例重启后被重置（RDS 尤其常见）
定位高内存线程：按用户+当前分配量排序
别直接看全局总和，先抓“谁在吃”——用线程级内存视图快速筛出异常账号或连接：
- 执行：
SELECT user, host, SUM(current_number_of_bytes_used)/1024/1024 AS MB FROM performance_schema.memory_summary_by_account_by_event_name GROUP BY user, host ORDER BY MB DESC LIMIT 5; - 若某
user持续占 60MB+，且该账号对应的是业务应用（非root或backup），基本可锁定为问题源头 - 注意
host字段：如果是%或内网大段 IP（如10.0.%），说明连接池未收敛，可能有长连接泄漏或批量任务未释放资源
顺着线程 ID 查具体事件和 SQL 内容
拿到高内存的 user 后，要关联到真实线程和正在跑的语句，否则无法判断是游标没关、临时表溢出，还是大分组卡住：
- 查活跃线程：
SELECT THREAD_ID, PROCESSLIST_USER, PROCESSLIST_HOST, PROCESSLIST_DB, PROCESSLIST_INFO FROM performance_schema.threads t JOIN performance_schema.processlist p ON t.THREAD_ID = p.THREAD_ID WHERE PROCESSLIST_USER = 'xxx' AND PROCESSLIST_STATE = 'Executing' ORDER BY PROCESSLIST_TIME DESC LIMIT 3; - 对每个可疑
THREAD_ID，查它的内存明细：SELECT event_name, current_number_of_bytes_used/1024/1024 AS MB FROM performance_schema.memory_summary_by_thread_by_event_name WHERE THREAD_ID = 12345 ORDER BY current_number_of_bytes_used DESC LIMIT 5; - 重点关注：
memory/temptable/physical_ram（内存临时表）、memory/sql/Filesort（排序缓冲）、memory/sql/Query_cache（已弃用但若开启会误报）
区分“真消耗”和“假高内存”：看 RES vs PFS 统计差值
top 里看到 mysqld 占 14GB，但 performance_schema.memory_summary_global_by_event_name 加起来才 2GB？这不是数据不准，而是 MySQL 有大量内存不走 PFS 路径：
-
innodb_buffer_pool_size分配的内存不会出现在 PFS 的memory/innodb/*中，它走的是 mmap，只体现为进程 RSS - 复制线程的 relay log 缓存、Group Replication 的消息队列、JIT 解析器缓存等，也不受 PFS 控制
- 执行：
SELECT SUM(CAST(REPLACE(current_alloc,'MiB','') AS DECIMAL(10,2))) FROM sys.memory_global_by_current_bytes;—— 这个视图比原生 PFS 更全，但依然不含 buffer pool；若结果仍远小于 top 的 RES，就该去查innodb_buffer_pool_size配置是否过大，或是否存在外部工具（如 pt-mysql-summary）误读了虚拟内存
真正难处理的不是“哪个线程内存高”，而是“为什么这个线程持续不释放”——比如游标没 close、事务没 commit、或是存储过程里循环中反复建临时表。这些行为在 PFS 里表现为 THREAD_ID 对应的内存统计随时间缓慢爬升，且 PROCESSLIST_STATE 长期卡在 Creating sort index 或 Copying to tmp table。这时候光 kill 线程没用，得回代码里改逻辑。
