从库设 sync_binlog 没用，因其仅控制本机写 binlog 时的刷盘行为；默认不生成 binlog（log_slave_updates=0），该参数完全不生效；即使开启，也仅在级联复制中作为中间主库时才有意义，此时已非纯粹从库。
从库不需要调 sync_binlog 和 innodb_flush_log_at_trx_commit 来提升复制性能——这两个参数对从库的数据安全性无意义，还可能引入一致性风险。
为什么从库设 sync_binlog 没用？
从库不生成 binlog（除非开启 log_slave_updates），sync_binlog 控制的是“本机写 binlog 时是否立即刷盘”。默认关闭 binlog 写入的从库，该参数完全不生效；即使开了 log_slave_updates，也只在级联复制中作为中间主库才需关注其 binlog 持久性——此时它已不是纯粹的从库，而是兼具主库角色。
常见错误现象：SHOW VARIABLES LIKE 'sync_binlog' 返回 1，但 SHOW MASTER STATUS 显示 File 为空或长期不变，说明 binlog 根本没启用，参数只是摆设。
- 检查是否真在写 binlog：
SELECT @@log_slave_updates;必须为 1，且SHOW BINARY LOGS有输出 - 云数据库（如阿里云 RDS）通常强制禁用从库 binlog，
sync_binlog被忽略或只读 - 设成 0 或 N 不会加快 SQL 线程回放速度——回放瓶颈在解析、锁竞争、磁盘随机写，不在 binlog 刷盘
从库设 innodb_flush_log_at_trx_commit=2 的真实影响
从库的事务提交由 SQL 线程驱动，不是应用直连发起。设为 2 确实减少 redo log 刷盘频率，但收益极小：SQL 线程本身是单线程（或有限并行），redo 日志写入压力远低于主库；而风险明确——主机断电时，最后约 1 秒已回放但未刷盘的事务会丢失，导致从库数据比主库少，Seconds_Behind_Master 归零但数据实际落后。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 若开启
relay_log_recovery=1（推荐），MySQL 重启时会自动重建 relay log，避免因崩溃导致 relay log 损坏，这比调低innodb_flush_log_at_trx_commit更有效 - 真正影响从库延迟的是
innodb_buffer_pool_size是否足够缓存热点表、slave_parallel_workers是否合理、以及大事务/DDL 是否阻塞 - 设为 0 更危险：崩溃后可能丢失多秒回放进度，且无法通过 relay log 恢复，因为日志已在内存中被覆盖
从库真正该调的参数组合
优化方向应聚焦“稳定追上主库”，而非模拟主库的持久化策略。关键点在于降低回放抖动、避免 IO 阻塞、加速元数据操作。
-
innodb_flush_log_at_trx_commit=1—— 保持默认，确保回放事务落盘可靠；降为 2 的收益微乎其微，却让故障恢复变得不可预测 -
sync_binlog=1或忽略 —— 仅当开启log_slave_updates且需对外提供 binlog 时才需设为 1；否则不用管 -
innodb_buffer_pool_size至少设为物理内存的 60% —— 缓存 relay log 对应的表页，减少回放时的磁盘随机读 -
slave_parallel_type=LOGICAL_CLOCK+slave_parallel_workers=4~8—— 在支持并行回放的 MySQL 5.7+ 上，这才是降低延迟的主力 - 禁用
innodb_doublewrite=OFF？不要——从库同样需要防止部分页写失败，尤其使用机械盘或旧 SSD 时
最容易被忽略的一点：从库的 innodb_flush_log_at_trx_commit 和 sync_binlog 即使调了，也不会让 Exec_Master_Log_Pos 更快推进——位置更新发生在事务提交后，而刷盘只是提交的一个子步骤。把精力放在 relay log I/O、buffer pool 命中率和并行度上，比纠结这两个参数实在得多。
