必须显式启用memory/% instruments和global/thread consumers，否则内存视图为空；验证需看show engine performance_schema status最后一行是否为ok；再查memory_summary_global_by_event_name，重点关注high_number_of_bytes_used持续上涨。
performance_schema 内存监控没真正启用
很多人执行 SHOW VARIABLES LIKE 'performance_schema' 看到 ON 就以为万事大吉，其实只是开关开了，memory/% instruments 和 consumers 很可能还关着——这会导致所有内存视图返回空或零值，误判为“没泄漏”。
- 必须显式启用内存采集：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'memory/%'; - 同时打开全局和线程级消费者：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('global_instrumentation', 'thread_instrumentation'); - 验证是否就绪：
SHOW ENGINE PERFORMANCE_SCHEMA STATUS，只看最后一行是不是OK；不是就得重启 mysqld 或检查启动参数是否含--performance-schema=ON
查 memory_summary_global_by_event_name 定位内存大户
这是第一把刀。别只盯 CURRENT_NUMBER_OF_BYTES_USED，HIGH_NUMBER_OF_BYTES_USED（峰值）更关键——持续上涨不回落才是泄漏信号。
- 重点关注三类事件：
memory/innodb/mem0mem（InnoDB 内部结构，非 buffer pool）、memory/temptable/allocator（内存临时表）、memory/sql/thd（每个连接的线程上下文） -
memory/innodb/mem0mem长期高位？结合SHOW ENGINE INNODB STATUS查SEMAPHORES和TRANSACTIONS区块，大概率是未提交事务或锁等待堆积，导致字典缓存/锁结构膨胀 -
memory/temptable/*异常高？立刻检查tmp_table_size和max_heap_table_size——设成 2G 不是“更稳”，是鼓励引擎把大结果全塞进内存，反而诱发 OOM - 看到
memory/sql/Query_cache？赶紧关掉：SET GLOBAL query_cache_type = 0，MySQL 8.0 已废弃，留着只会碎片化内存
按线程查 memory_summary_by_thread_by_event_name 找肇事连接
很多“泄漏”其实是应用端连接池没配好，几百个空闲连接堆在那，每个都带着 sort_buffer_size、read_buffer_size 等线程级 buffer，RSS 就无声无息涨上去了。
- 执行：
SELECT thread_id, user, event_name, sys.format_bytes(CURRENT_NUMBER_OF_BYTES_USED) AS memory_used FROM performance_schema.memory_summary_by_thread_by_event_name WHERE CURRENT_NUMBER_OF_BYTES_USED > 1024*1024 ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC LIMIT 20; - 如果发现某个
thread_id的memory/sql/thd持续不降，且对应user是后台统计服务或定时任务，基本可锁定为连接未释放 - 注意：
memory/sql/thd的增长是线性的，连接数翻倍，这部分内存几乎翻倍——它本身不泄漏，但配置不当会让它“看起来像泄漏”
别忽略 OS 层 RSS 与 MySQL 参数的联动效应
Performance Schema 告诉你“内存花在哪”，但不告诉你“为什么花得停不下来”。真正的瓶颈常藏在 OS 层和 MySQL 全局参数协同失衡里。
-
innodb_buffer_pool_size占用的是预分配虚拟内存，物理 RSS 不会随负载线性涨；但tmp_table_size+max_connections×sort_buffer_size这类组合，会直接撑满 RSS - Linux 的 THP（Transparent Huge Pages）开启时，MySQL 的 malloc 分配容易产生碎片，
top看 RSS 涨得快但 Performance Schema 里找不到明显大户——此时需echo never > /sys/kernel/mm/transparent_hugepage/enabled - 第三方组件（如某些备份工具、审计插件）可能绕过 Performance Schema 记录内存分配，得结合
pstack和malloc_info输出交叉验证
SHOW ENGINE PERFORMANCE_SCHEMA STATUS 是否真为 OK；只要这一步漏了，后面所有查询都是在看假数据。
