数据库总结
主从复制的核心价值
-
负载分担：将读请求分发到从库，主库专注于处理写操作，提高整体系统的并发处理能力。
-
高可用性：当主库发生故障时，可以快速将从库提升为主库，减少服务中断时间。
-
数据备份：从库可以作为热备份，避免因备份操作影响主库性能。
-
读写分离：针对读多写少的应用场景（如网站、社交媒体），实现数据库的读写分离架构。
-
地理分布式部署：在不同地理位置部署从库，降低延迟，提高不同地区用户的访问速度。
-
数据分析和报表生成：在从库上执行复杂查询和报表生成，不影响主库的正常业务运行。
-
升级和迁移：可以在从库上进行系统升级测试，验证通过后再切换，减少风险。
-
数据安全：通过主从复制在不同存储设备上保存多份数据副本，提高数据安全性。
基于QPS的决策阈值
- 单库极限：MySQL单实例通常支持5000-10000 QPS
- 读写分离时机：
- 读QPS > 1000（小型应用）
- 读QPS > 5000（中型应用）
- 读写比例 > 10:1时效果最佳
基于数据量的决策阈值
| 数据量级 | 单表行数 | 主从复制必要性 | 主要考虑因素 |
|---|---|---|---|
| 小型 | 1万行 | 低到中等 | 主要用于高可用性和备份 |
| 中型 | 10万行 | 中等到高 | 兼顾性能扩展和高可用性 |
| 大型 | 1000万+行 | 非常高 | 必须考虑分库分表 |
不同数据量级的性能特征
-
1万行表：
- 响应时间通常10-50ms
- 索引B+树高度2-3层
- 备份时间短，影响小
- 适合单库架构+备份从库
-
10万行表：
- 复杂查询可能超过100ms
- 索引维护成本增加
- 锁竞争开始影响并发
- 建议1主1从起步架构
实施建议
- 提前规划：数据增长快的应用应尽早实施
- 按需扩展：根据实际QPS和数据增长调整从库数量
- 监控延迟：复制延迟是主从架构的关键指标
- 读写分离策略：
- 写操作走主库
- 读操作走从库
- 实时性要求高的读操作可考虑主库
根据单表数据量的不同（1万行和10万行），数据库主从复制的需求和优化策略也有所不同：
单表1万行场景
主从复制必要性：低到中等
- 性能表现：单表1万行数据通常可以在单库环境下良好运行
- 查询性能：普通查询响应时间一般在10-50ms范围内
- 索引效率：索引维护成本低，B+树高度通常为2-3层
- 主从复制考虑因素：
- 主要考虑高可用性而非性能扩展
- 适合需要数据备份和灾难恢复的场景
- 读QPS超过500时可以考虑读写分离
- 数据备份不影响在线业务（备份窗口小）
单表10万行场景
主从复制必要性：中等到高
- 性能表现：单表10万行开始显现性能瓶颈
- 查询性能：复杂查询响应时间可能超过100ms
- 索引效率：索引大小增加，维护成本提高
- 主从复制考虑因素：
- 读QPS超过1000时明显受益于主从分离
- 查询优化变得重要（需要合理索引设计）
- 备份时间增长（可能需要数分钟）
- 事务锁竞争开始影响并发性能
- 数据恢复时间延长，高可用性需求增加
性能对比
| 数据级别 | 单表1万行 | 单表10万行 |
|---|---|---|
| 表大小 | 通常几MB到几十MB | 通常几十MB到几百MB |
| 全表扫描时间 | 毫秒级 | 可能达到秒级 |
| 索引查询时间 | 通常<10ms | 可能10-50ms |
| 主从复制必要性 | 主要用于高可用 | 同时用于性能扩展和高可用 |
架构建议
-
单表1万行时：
- 可以先采用单库架构，确保索引优化
- 考虑配置一个从库用于备份和监控
- 重点关注数据备份策略而非读写分离
-
单表10万行时：
- 建议实施主从复制架构（1主1从起步）
- 将报表查询、数据分析等操作引导到从库
- 实现基础的读写分离（写操作走主库，读操作走从库）
- 开始监控复制延迟，确保数据一致性
-
过渡期优化：
- 当单表从1万行增长到10万行过程中，应提前规划主从架构
- 监控查询性能指标，当平均响应时间超过100ms时考虑迁移
- 数据增长速度快的应用（如每日增长5%）应更积极地实施主从架构
对于大多数业务应用，单表达到5-10万行时是评估和实施主从复制的理想时机，可以在性能问题显现前做好准备。
具体阈值参考
-
小型应用转主从时机 ：
- 读QPS > 1000
- 数据量 > 10GB
- 单表记录数 > 100万
-
中型应用转主从时机 ：
- 读QPS > 5000
- 数据量 > 50GB
- 单表记录数 > 1000万
-
大型应用主从架构 ：
- 主库1个 + 从库3-5个（根据读QPS需求扩展）
- 数据分片考虑（每个分片数据量控制在500GB以内）
数据量相关场景
-
大数据量存储 ：
- 当单库数据量超过100GB-500GB时，单库性能下降明显
- 大表（超过1000万行）的查询性能急剧恶化，索引维护成本增加
-
备份和维护影响 ：
- 当数据量达到几十GB时，单库备份时间可能长达数小时，严重影响在线服务
- 主从复制可在从库执行备份，避免影响主库正常运行
-
数据增长趋势 ：
- 当数据量增长率预计超过每月20%时，提前规划主从架构
- 大型应用中，数据量通常3-6个月翻一倍，需要扩展性方案
