主从架构性能问题需从复制延迟、资源使用、配置合理性三方面诊断优化：延迟超1–3秒提示瓶颈；主库cpu高或从库io高、网络丢包均会加剧延迟；调整sync_binlog、并行复制等参数并匹配业务场景（如读写分离、半同步）可有效优化。
看延迟：复制延迟是第一信号灯
延迟（Replication Lag）是最直观的性能指标，单位为秒，可通过 SHOW SLAVE STATUS\G 中的 Seconds_Behind_Master 查看。但要注意：该值为 0 不代表无延迟（比如从库 SQL 线程空闲时会显示 0），而持续大于 1–3 秒，尤其在业务高峰时段飙升，基本可判定存在瓶颈。
常见延迟诱因包括：
- 主库执行了大事务（如单条 UPDATE 影响百万行），从库必须串行回放，耗时翻倍；
- 从库 SQL 线程单线程回放（MySQL 5.6 之前默认），无法利用多核 CPU；
- 从库磁盘 I/O 能力弱（如使用机械盘或 IOPS 不足），relay log 写入或回放慢；
- 主库 binlog format 设置为 STATEMENT，遇到函数、临时表等非确定性语句，从库执行可能更慢甚至出错。
查资源：CPU、IO、网络三者缺一不可
主从同步本质是 I/O 密集型+CPU 密集型任务，需同步观察两端服务器资源：
- 主库：高 TPS 下 CPU 持续 >80%，或 binlog_dump 线程 占用过高，说明 dump 压力大，可能因从库拉取慢导致主库堆积；
- 从库：SQL 线程 CPU 占用高 + 磁盘 await 高 + iowait 高 → 回放卡在 IO；若 CPU 高但 iowait 低 → 可能是复杂 SQL 解析/执行开销大；
- 网络：主从间带宽打满（如千兆网卡持续 >900Mbps）、丢包率上升、RTT 波动大，会导致 I/O 线程频繁重传，relay log 写入不及时。
验配置：参数不合理会放大底层缺陷
很多延迟问题表面在硬件，根子在配置。几个关键参数要重点核对：
- sync_binlog=1 & innodb_flush_log_at_trx_commit=1：保证主库数据安全，但会显著降低写入吞吐，若业务允许一定风险，可调为 sync_binlog=1000 或 innodb_flush_log_at_trx_commit=2；
- slave_parallel_type=LOGICAL_CLOCK + slave_parallel_workers=4~8：开启基于组提交的并行复制，大幅提升从库回放速度（需 MySQL 5.7+，且主库 binlog_format=ROW）；
- innodb_buffer_pool_size 过小 → 从库频繁读盘回放；read_buffer_size / sort_buffer_size 过小 → 复杂查询回放时大量磁盘临时表；
- 未启用 slave_preserve_commit_order=ON（配合并行复制）→ 可能导致从库主键冲突或数据错乱，被迫降级为单线程回放。
做优化：从场景出发，不堆技术
优化不是调参比赛，而是匹配业务特征：
- 读多写少、允许秒级延迟 → 用异步复制 + 读写分离，加缓存（Redis）挡掉 70% 以上读请求；
- 强一致性要求（如金融类）→ 启用半同步复制（rpl_semi_sync_master_enabled=ON），并搭配 semi_sync_master_timeout 控制等待上限，避免主库阻塞过久；
- 大表批量更新频繁 → 拆分大事务（每 1 万行 commit 一次），或改用 pt-archiver 工具分批处理，避免主从同时卡死；
- 从库承担报表类慢查询 → 单独部署只读从库，关闭 query cache（已弃用）、禁用 binlog（skip_slave_start + log_slave_updates=OFF），专注提升查询响应。
