从库oom崩溃主因是内存参数与只读负载不匹配，尤其innodb_buffer_pool_size和performance_schema配置不当；需关闭innodb_dedicated_server、按需关闭performance_schema、校验buffer pool大小合法性，并针对从库负载调低各缓冲参数。
从库OOM崩溃，大概率不是MySQL bug，而是内存参数与只读负载不匹配，尤其innodb_buffer_pool_size和performance_schema配置不当——调错地方会白忙活。
为什么从库比主库更容易OOM？
从库虽不写入，但有三类额外内存压力：SQL线程回放时的临时表/排序缓冲、并行复制（slave_parallel_workers）带来的多线程buffer叠加、以及performance_schema在高并发复制下对事件内存的持续分配。更关键的是，很多人直接复用主库配置，而主库的innodb_buffer_pool_size是按写+读混合负载设的，从库却常被用于报表查询，导致缓冲池被大范围扫描占满又无法释放。
- 从库的
innodb_buffer_pool_size不需要和主库一样大，尤其当它不承担写压力时 -
performance_schema在8.0默认开启，其内存占用随复制线程数线性增长，从库若开16个并行worker，内存开销可能翻倍 - 从库执行
SELECT ... FOR UPDATE或长事务时，undo日志和锁结构仍会驻留内存，但监控常被忽略
必须立即检查的三个参数
别先改配置，先确认是否已被误设：
-
innodb_dedicated_server=ON：MySQL 8.0默认启用，会根据总内存自动设innodb_buffer_pool_size。但从库常与Redis/Nginx混部，这个“专用服务器”假设完全不成立——查SHOW VARIABLES LIKE 'innodb_dedicated_server';，若为ON，立刻关掉 -
performance_schema=ON：查SHOW VARIABLES LIKE 'performance_schema';。若从库仅做数据同步+简单查询，建议直接关：SET PERSIST performance_schema = OFF;（需重启生效，或用SET GLOBAL动态关，但部分表会失效） -
innodb_buffer_pool_size是否合法：它必须是innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances的整数倍（默认chunk=128MB）。设15g这种值会被向下取整到14.875g，差那125MB可能就是OOM临界点——查SHOW VARIABLES LIKE 'innodb_buffer_pool_size';确认实际生效值
从库内存参数推荐值（以32GB物理内存为例）
目标是压住RSS在22–26GB区间，给OS和复制线程留足余量：
-
innodb_buffer_pool_size = 16g：从库读负载集中，但无需预留大量空间给写缓存；16GB足够覆盖热数据，且避开innodb_dedicated_server的激进策略 -
innodb_buffer_pool_instances = 8：避免单实例锁争用，尤其在并行复制场景下 -
tmp_table_size = max_heap_table_size = 64M：从库报表查询易建大临时表，但设太高会挤占buffer pool；64MB是平衡点，超限自动落盘比OOM强 -
sort_buffer_size = join_buffer_size = 512K：从库复杂JOIN少，设太高反而每个连接都吃内存；保持默认或略降更安全
注意：innodb_log_buffer_size这类参数从库可设小（如4M），因无redo日志生成压力；而read_buffer_size等全表扫描参数，若从库不做ETL，保持默认128K即可。
容易被忽略的OOM诱因
调完参数还OOM？重点看这三点：
- 复制SQL线程正在执行
ALTER TABLE或CREATE INDEX：这类操作在从库会触发大量内存临时表，且不走tmp_table_size限制——监控SHOW PROCESSLIST里是否有Waiting for handler commit状态的线程 -
innodb_buffer_pool_dump_at_shutdown=ON+ 大缓冲池：从库重启前dump几百MB文件，期间内存峰值飙升，可能触发OOM killer——生产环境建议关掉 - 未限制
max_connections：即使从库不对外服务，监控工具或DBA误连也会创建连接，每个连接基础消耗约256KB（thread_stack），500连接就吃掉128MB
真正卡点不在“设多大”，而在“谁在偷偷吃内存”。performance_schema.memory_summary_global_by_event_name这张表必须查，它能告诉你memory/sql/Query_cache（已废弃但残留）、memory/innodb/buf_buf_pool、memory/performance_schema/table_handles谁在排名前三——没数据就别瞎调。
