从库OOM与主库配置无关，主因是本地innodb_buffer_pool_size超MemAvailable且未预留OS/agent空间，叠加SQL线程重放开销、performance_schema、table_open_cache_instances等隐性内存消耗；须用dmesg确认OOM、cat /proc/meminfo | grep MemAvailable校准上限，并在线调小buffer pool（字节单位、整数倍约束）同时压控配角内存源。
从库OOM和主库配置没关系，先确认是不是它自己吃撑了
主从复制场景下，从库OOM和主库参数基本无关——innodb_buffer_pool_size、sort_buffer_size这些全是从库本地配的。很多运维一看到从库挂了就去改主库，白忙活。真正要盯的是从库自己的内存水位和负载特征。
第一步必须确认：是不是从库被oom-killer干掉的？执行：dmesg -T | grep -i "killed process" | grep mysqld。如果有输出且时间戳和MySQL崩溃时间对得上，才是真OOM；否则可能是SQL线程卡死、磁盘满或网络中断。
- 别信
free -h里的MemTotal，云主机（比如阿里云共享型、AWS t3）这个值严重虚高 - 真正能分给MySQL的硬上限是：
cat /proc/meminfo | grep MemAvailable，这个值减去2–4GB（OS+agent+备份脚本）才是安全边界 -
ps aux --sort=-%mem | head -5看mysqld是否真排第一，如果不是，先杀掉那个吃内存的Python/Java进程
从库比主库更容易OOM，因为多了SQL线程和重放开销
从库除了承担读流量，还要跑SQL线程重放binlog。这个过程会额外吃三块内存：
-
innodb_buffer_pool_size本身没变，但重放时大量INSERT/UPDATE触发页加载+undo生成，buffer pool压力更大 - 每个重放事务都会用到
sort_buffer_size、join_buffer_size——这些是“每连接”分配的，SQL线程算作一个连接，但它可能并发重放多个事务，缓冲区实际占用会浮动 - 如果开了
performance_schema且启用了memory/% = COUNTED，memory/sql/sp_head::main_mem_root会在重放触发器时飙升，尤其表上有几十个触发器时，单次重放就能吃掉几GB
查实时内存分布：SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED FROM performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME LIKE 'memory/sql/%' ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC LIMIT 5。如果memory/sql/sp_head::main_mem_root排前三，基本就是触发器在捣鬼。
在线压内存的关键：调小buffer pool但别断SQL线程
从库OOM后最急的事不是重启，而是立刻释放内存，否则下次启动直接失败。MySQL 5.7+支持在线调小innodb_buffer_pool_size，但必须守规矩：
- 单位只能是字节：
SET GLOBAL innodb_buffer_pool_size = 1073741824（即1GB），写1G会报错 - 新值必须是
innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的整数倍，默认chunk_size=128MB、instances=8 → 最小步进1024MB；设1536MB可以，设1200MB会被静默截断 - 调小过程是渐进式释放，查
SHOW STATUS LIKE 'Innodb_buffer_pool_resize_status'看进度，期间SQL线程照常运行，别中断连接 - 永久生效仍需改配置文件：
innodb_buffer_pool_size = 1G（这里可以带单位），但只在下次重启后固化
容易被忽略的三个“配角”内存源
调小innodb_buffer_pool_size后还OOM，大概率是这三个非buffer pool组件在偷吃：
-
table_open_cache_instances：默认16，每个instance都缓存一份表结构。从库重放时频繁打开表，实例数越多，内存翻倍越狠。临时方案：SET GLOBAL table_open_cache_instances = 1 -
performance_schema：默认开启，但performance-schema-instrument = 'memory/% = COUNTED'会让内存监控自身吃掉1–2GB。不依赖深度诊断时，直接关：SET GLOBAL performance_schema = OFF（需重启才彻底释放） - 数据字典内存：
SHOW ENGINE INNODB STATUS\G里搜dictionary memory allocated，如果显示几百MB甚至几个GB，说明表数量多（比如20w+张表）、table_open_cache又设得大，这部分内存不计入buffer pool，但一样压垮系统
从库的内存问题从来不是单点故障，而是buffer pool + SQL线程开销 + 配套组件三者叠加的结果。调参时盯着MemAvailable和Innodb_buffer_pool_wait_free两个指标，比盲目加内存管用得多。
