确认OOM杀掉SQL线程需先查dmesg -T | grep -i "killed process.*mysqld"，若有记录再结合free -h中available长期低于500MB即可坐实；头号原因是innodb_buffer_pool_size设置过高，尤其小内存从库应设为768M并满足热数据×1.2、OS留≥1.8GB、chunk_size×instances整数倍三条件，且必须重启生效。
怎么确认是OOM杀掉了SQL线程
从库同步卡住但没报错，SHOW SLAVE STATUS\G里Seconds_Behind_Master持续涨、Slave_SQL_Running_State停在“Reading event from the relay log”或“Updating”，大概率不是网络问题，而是系统内存耗尽后干掉了mysqld。直接查证据：dmesg -T | grep -i "killed process.*mysqld"。有这条记录，基本坐实OOM；再跑free -h看available值——长期低于500MB就危险了。
为什么innodb_buffer_pool_size是头号嫌疑
从库比主库更易OOM：它要扛读请求 + 应用relay log的写压力，但很多人照搬主库配置，把innodb_buffer_pool_size设得过高。比如2GB内存的ECS上设1.5G，OS和MySQL其他线程至少抢走800MB，实际只剩200MB可用，SQL线程一开大事务就卡死。
- 别信
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'返回的值，那是配置值；真占多少内存，得看cat /proc/$(pgrep mysqld)/status | grep VmRSS - 云上小内存从库（如2GB）推荐设为
768M，对应innodb_buffer_pool_instances=4（默认chunk大小128M，768M = 128M × 6） - 这个值必须同时满足三件事：大于热数据总量×1.2、给OS留≥1.8GB、是
chunk_size × instances的整数倍
调小buffer pool时容易踩的坑
不是简单砍掉一半就完事。填个600M进去，MySQL 8.0会静默向下取整成512M（因为128M × 4），导致缓冲池远小于预期，同步期间频繁刷脏页、IO拉满。
- 先算热数据量：
SELECT SUM(data_length + index_length) FROM information_schema.tables WHERE engine='InnoDB' AND table_schema NOT IN ('mysql','performance_schema','information_schema'); - 再检查OS余量：
free -h的available值稳定≥1.8GB才算安全 - 最后核对倍数关系：设
innodb_buffer_pool_chunk_size=128M、innodb_buffer_pool_instances=4，那合法值只能是512M、640M、768M、896M…
改完配置后必须重启mysqld
SET GLOBAL innodb_buffer_pool_size在MySQL 5.7+虽支持动态调整，但只适用于增大且需满足严格条件（如新值是当前值的整数倍、实例数不变等），而从库OOM场景下几乎总是需要**减小**，必须重启生效。改完/etc/my.cnf里的innodb_buffer_pool_size后，执行sudo systemctl restart mysqld，再立刻验证：SHOW SLAVE STATUS\G看Seconds_Behind_Master是否开始下降，free -h确认available回升到1.8GB以上。
真正麻烦的不是调参本身，而是热数据量会变、OS后台进程内存占用不固定、甚至同一台机器上跑着Redis或Java应用——这些变量叠加起来，让“安全值”永远是个动态边界，而不是一个固定数字。
