结论：slave_pending_jobs_size_max必须大于主库max_allowed_packet，否则触发错误1864导致sql线程中断；其单位为字节，需动态执行stop slave、set global、start slave调整，并在my.cnf中配置以永久生效，推荐值比主库max_allowed_packet多1~2mb缓冲，且须与slave_parallel_workers等参数协同优化。
直接结论：这个参数不是“越调越大越好”，而是必须比主库 max_allowed_packet 大，否则会触发错误 1864 导致 SQL 线程中断。
为什么修改后还会报错 1864？
常见现象是执行 START SLAVE 后，SHOW SLAVE STATUS 显示：Last_Errno: 1864Last_Error: Cannot schedule event Write_rows, relay-log name ./mysql-relay-bin.001304, position 416228895 to Worker thread because its size 16777357 exceeds 16777216 of slave_pending_jobs_size_max.
这说明当前 binlog 事件大小（16777357 字节）超过了 slave_pending_jobs_size_max 当前值（16777216 字节），差了仅 141 字节 —— 不是配置没生效，而是值设小了。
- 该参数单位是字节，不是 MB，
16777216 = 16M，但主库可能发来一个接近max_allowed_packet的大事务（比如批量更新 7 万行） - 必须确保
slave_pending_jobs_size_max > max_allowed_packet（主库的值），否则任何超过该阈值的单个事件都无法入队 - 查主库：运行
SHOW VARIABLES LIKE 'max_allowed_packet';，假设返回67108864（64M），那么从库至少要设为68000000或更高
怎么改才安全有效？
动态修改最常用，但要注意操作顺序和作用范围：
- 先停复制：
STOP SLAVE; - 再设值（推荐比主库
max_allowed_packet多留 1~2MB 缓冲）：SET GLOBAL slave_pending_jobs_size_max = 70000000; - 重启复制：
START SLAVE; - 验证是否生效：
SHOW VARIABLES LIKE 'slave_pending_jobs_size_max'; - 如果希望永久生效，需在
my.cnf的[mysqld]段落追加：slave_pending_jobs_size_max = 70000000，然后重启 MySQL 实例（否则实例重启后恢复默认值）
调多大才算合适？
没有固定“最佳值”，取决于你的复制负载和内存余量：
- 默认值在不同版本有差异：
MySQL 5.7常为134217728（128M），但某些旧部署可能是16777216（16M），务必先查清 - 生产环境常见设置区间是
67108864（64M）到1073741824（1G），不建议盲目设到 2G+，否则可能挤占 InnoDB 缓冲池或触发 OOM - 如果启用多线程复制（
slave_parallel_workers > 0），且观察到Seconds_Behind_Master波动剧烈、Relay_Log_Space持续增长，说明待处理事件积压严重，可尝试逐步上调（每次 +32M 观察） - 配合监控看
SHOW PROCESSLIST中是否有大量Worker thread处于Waiting for an event from sql thread状态，这是队列满的典型表现
真正容易被忽略的是：它必须和 slave_parallel_workers、slave_worker_queue_size 协同调整。单独调高 slave_pending_jobs_size_max 而不增加工作线程数，只会让积压更深、延迟更隐蔽。复制性能瓶颈从来不是单点参数能解决的。
