主从延迟怎么优化

主从延迟（Replication Lag）是指 MySQL / PostgreSQL 等数据库的主库写入后，从库未能及时同步数据的现象。优化思路通常分为架构层面、参数层面、SQL 层面和监控层面。下面以 MySQL 主从复制为主说明（其他数据库思路类似）。

一、先确认延迟原因

不同原因优化方式不同，常见原因：

1. 从库性能差（CPU、IO、内存不足）
2. 主库写入量过大（大事务、批量写入）
3. 从库单线程回放（旧版本 MySQL）
4. 网络延迟
5. 从库上有慢查询 / 统计任务
6. 大表 DDL 操作

二、架构与部署优化

1. 提升从库硬件

• 使用 SSD
• 提高 CPU 核数
• 增大内存（提高 buffer pool）

2. 减少从库压力

• 从库只做读，不做报表/统计
• 报表类查询走 专用只读实例
• 避免从库上跑定时任务

3. 网络优化

• 主从同机房 / 同可用区
• 使用低延迟内网
• 避免跨地域复制（如必须，考虑多活架构）

三、MySQL 复制参数优化（重要）

1. 开启并行复制（推荐）

MySQL 5.7+

slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8   # 根据 CPU 核数调整

MySQL 8.0

binlog_transaction_dependency_tracking = WRITESET
slave_parallel_workers = 16

2. 减少落盘等待

sync_binlog = 0或1（主库）
innodb_flush_log_at_trx_commit = 2（从库可接受）

3. 关闭从库 binlog（如不需要级联）

skip-log-bin

四、SQL 与业务优化

1. 避免大事务

❌ 错误示例：

DELETE FROM log WHERE create_time < '2020-01-01';

✅ 优化：

DELETE FROM log WHERE create_time < '2020-01-01' LIMIT 1000;

2. 避免全表更新

• 分批次
• 低峰期执行

3. 索引优化

• 从库回放依赖索引
• 缺索引会导致回放极慢

五、DDL 优化

• 使用 gh-ost / pt-online-schema-change
• 避免直接 ALTER TABLE

六、监控与告警

• 监控指标：
  • Seconds_Behind_Master
  • 回放线程状态
• 工具：
  • Prometheus + Grafana
  • pt-heartbeat（更精确）

七、极端场景方案

• 读写分离但允许短暂不一致（最终一致）
• 强一致读：关键业务读主库
• 使用 半同步复制（降低丢数据风险，不解决延迟）

总结一句话

主从延迟优化 = 提升从库回放能力 + 减少主库写入压力 + 避免从库被滥用

如果你愿意，可以告诉我：

• 使用的数据库（MySQL / PG / Redis）
• 版本
• 延迟大概多少秒
• 是否有大事务

我可以给你更具体的优化方案。