Performance Schema 是诊断 MySQL 内存“泄漏感”的核心工具，需启用 memory instruments 和 consumers，并通过 memory_summary_global_by_event_name 等视图定位内存大户，结合 OS 层 THP、malloc 碎片及第三方组件排查。
查 Performance Schema 内存事件：先确认是不是真泄漏
MySQL 本身几乎不会出现传统意义的 C 堆内存泄漏，但 RSS 持续上涨、OOM Killer 杀进程、top 看 mysqld 占用内存越跑越高——这些“泄漏感”90% 来自配置或使用失当。Performance Schema 是唯一能告诉你“内存到底花在哪”的内部仪表盘，但它默认可能没开全。
-
performance_schema必须为ON，且至少启用内存相关 instruments：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'memory/%'; - consumers 也要打开：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('global_instrumentation', 'thread_instrumentation'); - 别信
SHOW VARIABLES LIKE 'performance_schema'就完事了——得查状态：SHOW ENGINE PERFORMANCE_SCHEMA STATUS，最后一行显示OK才算真正就绪
看全局内存分配：揪出吃内存的“大户”
执行这条 SQL，直接看到当前谁在狂占内存：
SELECT event_name, sys.format_bytes(CURRENT_NUMBER_OF_BYTES_USED) AS used FROM performance_schema.memory_summary_global_by_event_name WHERE CURRENT_NUMBER_OF_BYTES_USED > 1024*1024 ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC LIMIT 10;
重点关注三类：memory/innodb/mem0mem（InnoDB 内存管理器）、memory/temptable/*（内存临时表）、memory/sql/*（如 memory/sql/thd 或 memory/sql/Query_cache）。
- 如果
memory/innodb/mem0mem长期高位且持续涨，不是 InnoDB 缓冲池（那是预分配的），而是内部结构（如锁系统、字典缓存）堆积，需结合SHOW ENGINE INNODB STATUS的SEMAPHORES和TRANSACTIONS部分交叉验证 -
memory/temptable/allocator异常高？说明大量 GROUP BY / DISTINCT / UNION 查询正在生成大内存临时表，检查tmp_table_size和max_heap_table_size是否设得过大（比如设成 2G），反而鼓励引擎滥用内存 - 看到
memory/sql/Query_cache？赶紧关掉——query_cache_type=0，MySQL 5.7+ 已废弃，留着只会碎片化内存
按线程追内存：找到“肇事连接”
很多泄漏其实是应用端没关连接，每个新连接都带一份线程级 buffer（sort_buffer_size、read_buffer_size 等），连上几百个，内存就无声无息堆上去了。
SELECT t.thread_id, p.user, p.host,
m.event_name,
sys.format_bytes(SUM(m.CURRENT_NUMBER_OF_BYTES_USED)) AS mem_used
FROM performance_schema.memory_summary_by_thread_by_event_name m
JOIN performance_schema.threads t USING (thread_id)
LEFT JOIN performance_schema.processlist p USING (thread_id)
WHERE m.CURRENT_NUMBER_OF_BYTES_USED > 0
GROUP BY t.thread_id, p.user, p.host, m.event_name
HAVING mem_used > 1024*1024
ORDER BY mem_used DESC
LIMIT 20;
- 注意
thread_id数值大的那些行——它们是用户连接，不是 MySQL 内部线程（如thread/sql/main的 thread_id 通常很小） - 如果发现某个
user@host对应多个线程，且每个都占几 MBmemory/sql/thd，基本可断定应用没复用连接池，或 JDBC 没配wait_timeout - JDBC 连接串里必须显式加：
?sessionVariables=wait_timeout=300,interactive_timeout=300，否则 MySQL 默认 8 小时，连接空闲着也攥着内存不放
别漏掉操作系统层：THP 和 malloc 碎片才是“影子推手”
Performance Schema 显示内存分配正常，但 ps aux --sort=-rss 里 mysqld RSS 还是每天涨 500MB？问题很可能在 OS 层。
- Linux 透明大页（THP）是 MySQL 的隐形杀手：
cat /sys/kernel/mm/transparent_hugepage/enabled如果输出是[always] madvise never，立刻改：echo never > /sys/kernel/mm/transparent_hugepage/enabled，并写入/etc/rc.local或 systemd drop-in 持久化 - glibc 默认 malloc 在长期运行服务中容易产生碎片——不是泄漏，但 RSS 不释放。可用
cat /proc/$(pgrep mysqld)/smaps | awk '/^Size:/ {sum+=$2} END {print sum " KB"}'看总分配量，再用gdb -p $(pgrep mysqld) -ex "call malloc_stats()" -ex quit 2>/dev/null | tail -10查看碎片率（fastbins和unsorted块多、system memory远大于in use就是典型碎片） - 真要深挖，别硬刚 gdb——换
TCMalloc（启动时加--malloc-lib=tcmalloc），它自带pprof和内存快照，比原生 malloc 可观测性强得多
最麻烦的情况，是 Performance Schema 里看不出异常，OS 层也查不出 THP 或 malloc 问题，但 RSS 就是稳升——这时候得怀疑第三方 UDF、审计插件或自定义存储引擎，它们不在 MySQL 内存统计体系里，却实实在在吃内存。
