内存泄漏表现为mysqld rss持续缓慢上涨，重启归零；而配置过大是启动即飙高。关键指标：innodb_buffer_pool_wait_free长期为0但memory/sql/sp_head::main_mem_root等持续增长，buffer pool hit rate正常但free buffers减少，memavailable持续下降。
怎么看是不是内存泄漏，而不是单纯配大了
OOM不等于配置错了，得先区分是“吃太饱”还是“漏了”。真实泄漏的表现是：mysqld进程RSS持续缓慢上涨，哪怕QPS稳定、无大查询、连接数恒定，ps aux --sort=-%mem | head -5里mysqld的RES值每小时涨几百MB，重启后归零又开始爬升。而单纯配置过高是启动即飙高、负载一上来就冲顶。
重点盯这三个指标：
-
Innodb_buffer_pool_wait_free长期为0，但performance_schema.memory_summary_global_by_event_name里memory/sql/sp_head::main_mem_root或memory/innodb/buf_buf_pool持续增长 -
SHOW ENGINE INNODB STATUS\G中Buffer pool hit rate正常（>95%），但Free buffers不断减少且不恢复 -
cat /proc/meminfo | grep MemAvailable显示系统可用内存持续下降，而free -h的available列同步萎缩
performance_schema真会内存泄漏，不是传说
MySQL 8.0默认开启performance_schema，但它在某些场景下确实存在已知内存泄漏——尤其是大量使用存储过程、触发器或开启全量memory/% instruments时。memory/sql/sp_head::main_mem_root单项可能悄摸吃掉2GB+，且不会随连接关闭释放。
临时止血操作（无需重启）：
- 关掉高危instrument：
UPDATE performance_schema.setup_instruments SET ENABLED = 'NO' WHERE NAME LIKE 'memory/%'; - 限制表结构缓存爆炸：
SET GLOBAL table_open_cache_instances = 1;（默认16，每个instance独立缓存） - 彻底关闭（生产环境可接受监控降级）：
SET GLOBAL performance_schema = OFF;，再改配置文件加performance_schema = OFF
注意：performance_schema = OFF必须在[mysqld]段写，放错位置（比如[client]）不生效。
调小innodb_buffer_pool_size不能只写数字
在线调小缓冲池是救命动作，但SET GLOBAL innodb_buffer_pool_size = 2G会直接报错——MySQL 5.7+只认字节单位，且必须是innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的整数倍（默认chunk_size=128MB）。
正确做法：
- 先查当前合法步长：
SELECT @@innodb_buffer_pool_chunk_size * @@innodb_buffer_pool_instances;（常见值134217728字节，即128MB） - 计算目标值：比如想设2GB，2*1024*1024*1024 = 2147483648，确认是否为134217728的整数倍（2147483648 ÷ 134217728 = 16，OK）
- 执行：
SET GLOBAL innodb_buffer_pool_size = 2147483648; - 观察进度：
SELECT * FROM INFORMATION_SCHEMA.INNODB_BUFFER_POOL_RESIZE_STATUS;，状态为Completed才算释放完毕
别用2G或2048M——语法错误；也别设非整数倍值，MySQL会静默截断到最近合法值，你以为设了2G，实际可能是1.875G，还误判效果。
查完泄漏源，还得防住隐性内存大户
buffer pool和performance_schema只是明面上的两个大头，真正让OOM反复发作的，常是这些不起眼的“积少成多”项：
-
max_connections设500，sort_buffer_size默认256KB → 光排序缓存理论峰值就是125MB，但若业务代码没控制连接池，实际活跃连接撑到300+，再叠加join_buffer_size、read_rnd_buffer_size，轻松吃掉1.5GB+ -
tmp_table_size和max_heap_table_size设太大（如512MB），一个GROUP BY扫千万行，就生成超大内存临时表，且不释放 - OS层面留的余量不够：
innodb_buffer_pool_size设到物理内存75%，但忘了MemAvailable比MemTotal小10–20%（尤其云主机），再扣掉agent、backup脚本、systemd-journald，实际安全上限可能只有60%
最易被忽略的是：调完buffer pool后，SHOW VARIABLES LIKE '%buffer%'里那些per-connection参数还在默认值上趴着，它们才是压垮骆驼的最后一根稻草。
