主从复制不能解决大数据量下的性能瓶颈，仅能分流读请求，写压力仍集中于主库，且从库延迟在高并发下易升高；适用前提是读远多于写且可接受秒级延迟。
主从复制本身不解决大数据量下的性能瓶颈
MySQL 主从复制只是数据同步机制，不是性能扩展方案。它能分流读请求（通过将 SELECT 发往从库），但写压力仍全部落在主库，且从库延迟在大数据量+高并发下极易升高——尤其当主库执行大事务、DDL 或批量导入时，Seconds_Behind_Master 可能飙升到数小时。
常见误判是“加了从库就读得快了”，实际中常遇到：从库 CPU/IO 跟不上主库节奏、网络带宽成为瓶颈、从库因锁等待或慢查询拖慢复制线程。
- 单表超 2000 万行 + 日增 50 万以上时，建议优先考虑分库分表，而非堆从库
- 从库数量并非越多越好；超过 3–5 个后，主库的 binlog dump 线程和网络开销会明显上升
- 启用
slave_parallel_workers > 0可缓解延迟，但需配合slave_parallel_type = LOGICAL_CLOCK，且对非 GTID 模式支持有限
评估是否适合，关键看读写比和一致性容忍度
主从适用的前提不是“数据量大”，而是“读远多于写”且“能接受秒级甚至分钟级延迟”。比如报表类查询、用户中心只读页、日志归档查询等场景可以接受从库数据滞后；但订单状态、库存扣减、支付回调等强一致场景必须直连主库。
可通过 SHOW GLOBAL STATUS LIKE 'Com_select' 和 SHOW GLOBAL STATUS LIKE 'Com_insert%' 快速估算读写比。若 Com_select / (Com_insert + Com_update + Com_delete)
- 业务层需明确区分读写流量，避免 ORM 默认走主库却误发读请求到从库
- 监控必须覆盖
Seconds_Behind_Master、Slave_SQL_Running_State、从库Slow_queries三者联动分析 - 不要依赖
read_only=ON防误写——它不阻止 SUPER 权限用户操作，也不防应用层用错误账号连从库写入
大数据量下主从同步延迟的典型根因
延迟不是随机发生的，往往对应具体操作模式。例如：主库执行 ALTER TABLE ... ADD COLUMN（尤其未用 ALGORITHM=INSTANT）、从库上运行未加索引的 DELETE FROM large_table WHERE ...、或主库批量插入时未控制 binlog_row_image=FULL 导致日志体积暴增。
诊断时优先查 SHOW PROCESSLIST 在从库看到的 SQL 线程状态：若长期卡在 Waiting for table metadata lock，说明有长事务阻塞 DDL；若卡在 Updating 且 State 不变，大概率是某条 UPDATE 匹配了全表扫描。
- 用
pt-heartbeat替代Seconds_Behind_Master做更精准延迟测量（后者在 IO 线程空闲时可能显示为 0，但 SQL 线程已积压） - 大表变更务必在低峰期做，并提前在从库验证执行时间；可考虑用
gh-ost或pt-online-schema-change规避锁表 - 避免在从库开启
query_cache_type=1—— MySQL 5.7+ 中该功能已废弃，且在高并发下反而加剧锁争用
真正影响评估结果的是运维复杂度，不是技术指标
一个 5TB 数据库配 3 个从库，看起来合理，但实际意味着：备份策略要覆盖 4 个实例、failover 脚本要处理不同延迟状态下的切换逻辑、监控告警需区分主从健康度、SQL 审计日志要关联主从执行路径……这些隐性成本常被低估。
很多团队在数据量刚过 1TB 时就发现，花在调优复制延迟、排查偶发中断、修复误删从库数据上的时间，远超优化单实例性能带来的收益。
- 先确认是否真的需要“实时同步”——有些场景用
mysqldump+rsync每日同步一次即可满足需求 - 若必须用主从，建议从一开始就启用 GTID，避免传统基于 file/pos 的切换故障
- 不要跳过
sync_binlog=1和innodb_flush_log_at_trx_commit=1—— 它们会让主库稍慢，但能防止主库崩溃后从库出现数据不一致
