主库高并发写入同步压力源于写吞吐与复制能力失衡，需通过拆分大事务、启用并行复制、分流读负载及升级复制机制与硬件来缓解。
主库高并发写入带来的同步压力，本质是主从复制链路在“写吞吐”和“同步能力”之间失衡。缓解的关键不是单纯压降写流量，而是让写入更可控、复制更高效、架构更有弹性。
拆分大事务，避免单次写入成为延迟爆点
一条批量更新 5 万行的 SQL，主库可能毫秒级完成，但从库 SQL 线程要逐条回放，极易卡住。这不是并发量的问题，而是事务粒度问题。
- 业务层主动拆分：把大 INSERT/UPDATE 拆成每批 500～1000 行，加合理间隔（如 20ms），避免 binlog 瞬间膨胀
- 避免在高峰期执行 ALTER TABLE 等 DDL：这类操作会阻塞后续事务复制，建议在低峰或使用 pt-online-schema-change 工具
- 确认应用没有隐式大事务：比如未及时 commit 的长事务，或 ORM 自动生成的全表扫描+更新
启用并行复制，释放从库回放瓶颈
MySQL 5.7 起支持基于逻辑时钟（MTS）的多线程复制，5.6 可用库级别并行，8.0 支持 WRITESET 精细并行——核心是让从库不再只靠一个 SQL 线程硬扛。
- 检查当前复制模式：
SHOW SLAVE STATUS\G中查看 Slave_parallel_type 和 Slave_parallel_workers - 推荐配置（MySQL 8.0+）：
slave_parallel_type = LOGICAL_CLOCK，slave_parallel_workers = 8～16（根据 CPU 核数设） - 注意前提：主库需开启
binlog_transaction_dependency_tracking = WRITESET，且表有主键或唯一键
分流非核心读负载，降低从库资源争抢
从库延迟常被掩盖在“慢查询”背后——报表、导出、监控拉取等低优先级任务，和业务读请求混跑，抢占 IO 和 CPU。
- 为不同用途部署专用从库：比如“业务读从库”、“BI 报表从库”、“备份从库”，物理隔离资源
- 在中间件（如 ProxySQL、ShardingSphere）或应用层做读请求路由，按标签区分流量，避免报表 SQL 拖垮实时查询
- 限制慢查询：对从库启用
long_query_time = 1并记录慢日志，定期清理或优化耗资源查询
升级复制机制与硬件底座
当业务写入持续增长，单纯调参已不够，需考虑架构级加固。
- 半同步复制（semisync）可减少丢失风险，但不解决回放延迟；MGR（组复制）提供最终一致性+自动选主，适合强一致要求场景
- 主从磁盘必须同档：主库用 NVMe SSD，从库不能配 SATA 机械盘；CPU 核心数建议不低于主库的 70%
- 跨机房部署时，优先用内网专线而非公网；若必须跨云，启用压缩传输：
slave_compressed_protocol = ON
