从库load高是正常现象，因读负载集中、无写入干扰使缓存更饱满，并行复制线程空闲等待、大查询触发短生命周期线程及io等待等均推高就绪队列长度，但未必代表cpu过载。
从库 Load 高不是异常，而是典型资源使用模式差异的体现；主库写入干扰多、缓存更“动荡”，从库读负载集中、内存更“饱满”，两者不可直接对比。
为什么 top 看到的 Load 值从库更高？
Load 是系统过去 1、5、15 分钟内平均等待 CPU 的进程数，它反映的是“就绪队列长度”，不等于 CPU 使用率。从库 Load 偏高，常见原因有：
- 从库
SQL Thread或worker threads持续处于 runnable 状态（比如正在解析/回放大量ROW格式事件），但实际 CPU 利用率未必打满 - 从库执行
SELECT查询时触发大排序或临时表，生成大量短生命周期线程，推高 Load - 启用了
slave_parallel_workers > 0后，Coordinator 线程频繁分发任务，Worker 线程轮询等待事件，造成调度开销累积 - 从库磁盘 I/O 等待（如
relay log写入慢、innodb_buffer_pool换页压力大）导致进程阻塞在D状态，但 Load 仍会计入
SHOW PROCESSLIST 里一堆 Waiting for an event from Coordinator 是什么？
这是 MySQL 并行复制启用后典型的“假高 Load”信号。每个 worker thread 在空闲时会进入该状态，本质是阻塞在条件变量上等待 Coordinator 分配新事务 —— 它不消耗 CPU，但会被 top 统计为活跃进程，抬高 Load。
- 该状态本身无害，但若持续存在且
Seconds_Behind_Master > 0，说明 Coordinator 分发瓶颈或事务依赖太紧（如大量非LOGICAL_CLOCK兼容操作） - 检查
SHOW STATUS LIKE 'Slave_received_transactions'和Slave_retried_transactions差值：差值大 → relay log 解析/预取积压，可能受slave_pending_jobs_size_max限制 - 不要盲目调高
slave_parallel_workers，超过物理核数反而加剧上下文切换和锁竞争
从库内存占用高，真的是配置错了？
不是。从库 innodb_buffer_pool_size 配置和主库一样，但实际使用率更高，是因为：
- 从库几乎无写入，
innodb_buffer_pool_pages_dirty接近 0，页面长期驻留、淘汰频率低，缓存更“实” - 主库持续写入触发 LRU 链调整、脏页刷盘、自适应哈希重建等后台动作，缓冲池看起来“更空”
- 并行复制预取的 relay log 事件占用独立内存池（由
slave_pending_jobs_size_max控制），这部分不计入innodb_buffer_pool_size，但会显著提升VmRSS - 从库跑报表类查询时，
sort_buffer_size、join_buffer_size等 per-connection 缓冲区被批量激活，叠加效应明显
怎么判断是不是真过载？
别只盯 Load，要组合看三个维度：
- CPU：用
pidstat -p $(pidof mysqld) 1看 mysqld 进程的 %usr/%sys，持续 >80% 才算 CPU 瓶颈 - I/O：用
iostat -x 1看%util和await，SSD 上await > 10ms或%util == 100%表示磁盘饱和 - 复制进度：重点看
Exec_Master_Log_Pos是否稳定推进，以及Seconds_Behind_Master是否收敛 —— 如果它稳住不变，Load 高只是“忙但有效”，不用干预
真正要警惕的是：Load 高 + Seconds_Behind_Master 持续上涨 + IO Thread 和 SQL Thread 都 Running，那才是硬件或配置到了临界点。
