从库内存占用高于主库是正常现象，因其只读模式使缓冲池页长期驻留、淘汰压力小，used_gb更接近配置上限；同时slave_pending_jobs_size_max等隐性内存池不计入innodb_buffer_pool_size但显著推高RSS。
从库内存占用比主库高，不是配置错了，而是复制机制和查询模式天然导致的——它更“贪吃”内存，且这部分开销不体现在 innodb_buffer_pool_size 里。
为什么从库 innodb_buffer_pool_size 没调大，但实际 RSS 更高？
核心原因是：从库的缓冲池更容易被填满，且更“干净”。主库持续写入会触发页刷新、LRU链调整、脏页刷盘，导致缓冲池常有空闲；而从库只读不写，innodb_buffer_pool_pages_dirty 几乎为 0，数据页长期驻留、命中率高、淘汰压力小。所以即使配置值相同，从库的 used_gb 往往更接近上限。
验证方式：
SELECT ROUND(data_size/1024/1024/1024,2) AS used_gb FROM information_schema.innodb_buffer_pool_stats;
再对比：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
若从库 used_gb 达到配置值的 90%+，而主库仅 60%~70%，就不是配置问题，是使用模式差异。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
slave_pending_jobs_size_max 是隐性内存黑洞
MySQL 5.6+ 启用并行复制（slave_parallel_workers > 0）后，从库会预取 relay log event 并在内存中解包、解析、构造事务对象。这些对象存放在独立内存池，由 slave_pending_jobs_size_max 控制，不计入 innodb_buffer_pool_size，但直接抬高 VmRSS。
- 默认值：MySQL 5.7 是 128MB，MySQL 8.0 是 1GB
- 积压诱因：网络延迟高、SQL 线程处理慢、大事务拆分不均
- 典型表现：
SHOW PROCESSLIST中大量线程处于Waiting for an event from Coordinator；SHOW STATUS LIKE 'Slave_received_transactions'与Slave_retried_transactions差值明显增大 - 调低该值可缓解内存压力，但可能降低并行复制吞吐；建议搭配
slave_preserve_commit_order=ON和slave_parallel_type=LOGICAL_CLOCK一起评估
哪些操作会让从库内存“悄悄涨”？
除了复制机制，以下行为也会推高从库内存，且容易被忽略：
- 分析类查询（如报表、监控拉取）频繁执行
GROUP BY、ORDER BY或未走索引的JOIN，触发 per-connection 缓冲区（sort_buffer_size、join_buffer_size）按连接分配 - relay log 事件未及时消费，导致已解析但未应用的 event 长期驻留内存（尤其在主库突发大事务时）
- 启用
innodb_buffer_pool_load_at_startup且上次 dump 的热页多，启动后主动加载大量页 - 从库上开了
performance_schema且采集项过多，其内存池本身也会累积（虽然不属复制范畴，但叠加后加剧整体压力）
真正难调的不是单个参数，而是多个隐性内存池叠加后的“温水煮青蛙”效应——它们不报错、不告警，只在某次大查询或复制积压后突然让 VmRSS 跳变。盯住 slave_pending_jobs_size_max 和连接级缓冲的实际分配量，比盲目调小 innodb_buffer_pool_size 有效得多。
