MySQL OOM主因是innodb_buffer_pool_size超可用内存且未预留OS/agent/脚本空间，叠加performance_schema、table_open_cache、连接线程等隐性内存消耗；需用MemA vailable值校准buffer pool，并监控Innodb_buffer_pool_wait_free及持续命中率。
很多DBA把MySQL内存溢出（OOM）归咎于配置没调好，但真相往往更直接：是buffer pool吃得太满，加上其他内存组件没留余地，最终被Linux的oom-killer无情干掉。 问题的关键通常不是“加内存”，而是要让innodb_buffer_pool_size与系统真实的可用内存对齐，同时管住那些隐性的内存消耗大户。
怎么看是不是 buffer pool 导致 OOM
诊断OOM，别只看free -h输出的MemTotal——那只是个标称值，尤其在云主机（比如AWS的t3/t4系列）上，实际可用内存远低于这个数字。真正应该盯紧的是这几个指标：
首先，执行cat /proc/meminfo | grep MemA vailable。这个MemA vailable值才是内核当前能立刻分配的内存。一个实用的经验法则是：innodb_buffer_pool_size必须小于等于这个值，并且还要再减去2到4GB，用来保障操作系统、监控Agent以及备份脚本等后台进程的运行空间。
其次，用ps aux --sort=-%mem | head -5命令排查一下。确认除了mysqld之外，有没有其他进程在偷偷消耗内存，比如未做内存限制的Python监控脚本、同机的Ja va应用，或者开启了全量内存监控的performance_schema。
最后，在MySQL内部执行SHOW ENGINE INNODB STATUS\G，查找Innodb_buffer_pool_wait_free这个指标。如果它的值大于0，那就说明缓冲池已经满了，后台的page cleaner线程来不及淘汰旧页，系统正卡在性能极限的边缘，这是OOM前一个非常危险的信号。
怎么安全调小 innodb_buffer_pool_size
当面临OOM风险时，调小buffer pool往往比调大更紧迫——因为一旦被OOM Killer终止，MySQL可能连重启都困难。调整的重点在于“如何在线生效”以及“避免单位错误”。
对于MySQL 5.7及以上版本，支持在线调小。命令是：SET GLOBAL innodb_buffer_pool_size = 2147483648。这里有个关键细节：单位必须是字节，直接写2G会报错。
另外，设置的新值必须是128MB（即134217728字节）的整数倍，否则MySQL可能会静默截断或直接报错。
调整过程是渐进式的，内存会逐步释放。期间可以通过SHOW STATUS LIKE 'Innodb_buffer_pool_resize_status'来查看进度，切记不要中断执行命令的连接。
当然，这个在线修改只对当前实例有效。要永久生效，仍需修改配置文件（如my.cnf），加上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的组合。在高并发场景下，每个缓存实例都会保存一份表结构。如果数据库中有几百个带有大触发器的表，内存消耗会成倍上涨。临时缓解办法可以将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输出的瞬时命中率。
正确的做法是持续观察。可以使用命令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 MemA vailable把系统的内存底数摸清。否则，很可能在线调完参数，五分钟后又收到了oom-killer的“点名通知”。
