先执行dmesg -t | grep -i "killed process" | grep mysqld确认是否被oom-killer杀掉，若时间戳吻合则立即在线调小innodb_buffer_pool_size；再用cat /proc/meminfo | grep memavailable获取真实可用内存，减去2–4gb后设为buffer pool安全上限，并重点监控slave_pending_jobs_size_max、performance_schema中memory/sql/sp_head::main_mem_root等从库特有内存消耗点。
确认是不是真被OOM-killer干掉了
从库内存“持续升高”不等于马上会崩，但得先排除最危险的情况：它已经被系统盯上了。执行 dmesg -T | grep -i "killed process" | grep mysqld，如果有输出且时间戳和MySQL进程消失时间吻合，说明不是“升高”，是“刚被杀”。这时候别急着调参数，先保命——立刻压低 innodb_buffer_pool_size（在线可调），否则重启就再次触发OOM。
查真实可用内存，别信 free -h 的 used
云主机上 free -h 显示的 MemTotal 常虚高，真正能分给MySQL的是 MemAvailable。运行 cat /proc/meminfo | grep MemAvailable，拿这个值减去 2–4GB（OS、监控agent、备份脚本等必须预留空间），才是安全上限。比如 MemAvailable 是 10.2G，那从库的 innodb_buffer_pool_size 最多设到 6–7G，再高就是硬扛风险。
看从库特有的内存积压点：SQL线程 + relay log 预取
主库没这些负担，但从库有：
-
slave_pending_jobs_size_max控制并行复制预取事件的内存池，默认 MySQL 8.0 是 1GB，但网络延迟高或SQL线程慢时，实际驻留内存可能翻倍甚至更多，这部分不进performance_schema，得看/proc/`pidof mysqld`/status里的VmRSS和积压状态 - SQL线程重放 binlog 时，每个事务都会触发
sort_buffer_size、join_buffer_size分配，而它算作“一个连接”，但实际并发处理多个事务，缓冲区占用浮动大 - 如果开了
performance_schema且启用了memory/% = COUNTED，重放带触发器的表时，memory/sql/sp_head::main_mem_root可能单次飙升几GB
用 performance_schema 定位谁在吃内存
别只看总 RSS，要拆开看：
- 查全局内存大户：
SELECT EVENT_NAME, sys.format_bytes(CURRENT_NUMBER_OF_BYTES_USED) FROM performance_schema.memory_summary_global_by_event_name ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC LIMIT 5 - 重点盯：
memory/innodb/buf_buf_pool（正常）、memory/sql/sp_head::main_mem_root（触发器嫌疑）、memory/temptable/physical_ram（临时表泄漏） - 查用户级消耗：
SELECT user, host, SUM(current_number_of_bytes_used)/1024/1024 AS MB FROM performance_schema.memory_summary_by_account_by_event_name GROUP BY user, host ORDER BY MB DESC LIMIT 5，某业务账号长期占 100MB+ 就值得深挖
真正难搞的是那些不进 performance_schema 的内存：relay log 解析对象、JIT生成的执行计划、jemalloc 内部碎片——它们藏在 VmRSS 里，但查不到具体归属，只能靠压 innodb_buffer_pool_size + 控 slave_pending_jobs_size_max + 关不必要的 performance_schema instruments 来兜底。
