mysql oom主因是innodb_buffer_pool_size超可用内存且未预留os/agent/脚本空间，叠加performance_schema、table_open_cache、连接线程等隐性内存消耗；需用memavailable值校准buffer pool，并监控innodb_buffer_pool_wait_free及持续命中率。
MySQL 内存溢出（OOM）不是配置没调好，而是 buffer pool 吃得太满 + 其他内存组件没留余量，被 Linux oom-killer 直接干掉。 关键不是“加内存”，而是让 innodb_buffer_pool_size 和系统真实可用内存对齐，并压住其他隐性内存大户。
怎么看是不是 buffer pool 导致 OOM
别只看 free -h 的 MemTotal —— 那是标称值，云主机（比如 AWS t3/t4）实际可用远低于它。真正该盯的是：
-
cat /proc/meminfo | grep MemAvailable：这个才是内核当前能立刻分配的内存，innodb_buffer_pool_size必须 ≤ 这个值减去 2–4GB（OS + agent + backup 脚本） -
ps aux --sort=-%mem | head -5：确认有没有mysqld以外的进程偷偷吃内存（比如未限制的 Python 监控脚本、Java 应用、performance_schema开了全量 memory instrument） -
SHOW ENGINE INNODB STATUS\G里查Innodb_buffer_pool_wait_free：如果 > 0，说明 page cleaner 淘汰不过来，buffer pool 已经卡死在极限边缘
怎么安全调小 innodb_buffer_pool_size
调小比调大更急迫——OOM 后 MySQL 被 kill，再重启可能直接起不来。重点在“不重启也能生效”和“单位别写错”：
- MySQL 5.7+ 支持在线调小：
SET GLOBAL innodb_buffer_pool_size = 2147483648（单位是字节，不能写2G，否则报错） - 新值必须是 128MB 的整数倍（即 134217728 字节的倍数），否则会静默截断或报错
- 调小过程是渐进式释放，但期间
Innodb_buffer_pool_resize_status会显示进度，别中断连接 - 永久生效仍需改配置文件：
innodb_buffer_pool_size = 2G（这里可以带单位），然后下次重启才固化
为什么调小后还 OOM？盯住这三个非 buffer pool 内存源
buffer pool 只是 MySQL 内存大头，不是全部。OOM 常见真凶其实是这些“配角”：
-
performance_schema：如果开了memory/% = COUNTED，大量触发器/存储过程会让memory/sql/sp_head::main_mem_root单项吃掉几 GB——关掉或限制performance-schema-instrument -
table_open_cache+table_open_cache_instances：高并发下每个 instance 都缓存一份表结构，有几百个大触发器时，内存翻倍上涨；可临时设table_open_cache_instances = 1 - 连接线程自身开销：每个连接默认占
thread_stack（默认 256KB）、sort_buffer_size（默认 256KB）、tmp_table_size（默认 16MB）；如果 max_connections=3000，光临时表就可能撑爆 48GB
监控命中率不能只看单次 SHOW ENGINE
缓冲池“抖”不是慢，是忽快忽慢——同一句 SELECT COUNT(*) FROM log_2024 可能跑出 1 秒和 15 秒，本质是缓存是否命中。所以不能只看某次 SHOW ENGINE INNODB STATUS 里的 hit rate：
- 用
mysqladmin ext -i1 | grep -E "Innodb_buffer_pool_read|Innodb_buffer_pool_hit"持续观察波动，长期Innodb_buffer_pool_hit_rate - 更准的公式是：
(1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) * 100，注意分母是逻辑读，分子是磁盘读 - 如果
Innodb_buffer_pool_reads持续上升，而Innodb_buffer_pool_read_requests平稳，说明热数据反复被淘汰——这时调大 buffer pool 有用；但如果两者一起飙升，大概率是 SQL 在扫全表，调 buffer pool 白搭
最易被忽略的一点：buffer pool 不是越大越好，也不是越小越安全。它和 tmp_table_size、innodb_log_file_size、甚至 max_connections 是联动的。改一个之前，先用 ps aux --sort=-%mem 和 cat /proc/meminfo | grep MemAvailable 把底数摸清——否则在线调完，5 分钟后又被 oom-killer 点名。
