1. 主从架构与分库设计的核心价值在数据密集型应用的架构设计中主从复制Master-Slave Replication和分库Database Sharding是两种最基础也最关键的扩展方案。我经历过多个从单机数据库到分布式系统的升级项目这两种技术就像数据库领域的左右手——主从解决读写分离和高可用问题分库解决单库容量和性能瓶颈问题。以电商系统为例当用户量突破百万级时单机MySQL的QPS可能成为瓶颈。这时我们会先引入主从架构让主库处理订单创建、支付等写操作多个从库处理商品浏览、订单查询等读操作。当数据量进一步增长到TB级别就需要考虑按用户ID或地域进行分库把不同用户的数据分散到不同的物理库中。2. 主从架构深度解析2.1 主从复制的工作原理主从复制的核心是二进制日志binlog传输。我在配置MySQL主从时通常会关注以下几个关键参数# 主库配置 server-id 1 log_bin /var/log/mysql/mysql-bin.log binlog_format ROW sync_binlog 1 # 从库配置 server-id 2 relay_log /var/lib/mysql/mysql-relay-bin read_only ON重要提示binlog_format建议使用ROW模式能最大限度保证主从数据一致性。但在大事务场景下会产生大量日志需要权衡。2.2 主从延迟的实战解决方案主从延迟是最常见的生产问题。去年我们一个金融系统就因从库延迟导致用户看到过期余额。通过以下优化将延迟从15秒降到200ms内使用GTID复制替代传统文件位置复制从库配置slave_parallel_workers 8根据CPU核心数调整主库大事务拆分为小批次提交从库使用SSD存储并关闭不必要的查询3. 分库分表技术详解3.1 分片策略选型对比分片策略优点缺点适用场景范围分片易于扩展可能热点时间序列数据哈希分片分布均匀扩容复杂用户数据目录分片灵活调整需维护映射业务多变场景3.2 分库后面临的挑战在实施分库后我们遇到了三个典型问题及解决方案跨库JOIN改用冗余字段应用层聚合商品表冗余店铺名称分布式事务使用Seata的AT模式对账务系统采用TCC补偿全局唯一ID采用Leaf号段模式每个分片预分配ID区间4. 主从与分库的结合实践4.1 混合架构设计在日均订单百万级的零售系统中我们采用分层架构按区域分库华北、华东等每个分库配置1主2从使用ShardingSphere实现SQL路由通过Canal同步到Elasticsearch做聚合查询4.2 监控指标体系建立完善的监控是保证系统稳定的关键。我们部署的监控项包括主从延迟时间Prometheus Grafana分片负载均衡率自定义采集脚本慢查询TOP 10pt-query-digest连接池使用率Druid监控5. 典型问题排查手册5.1 主从复制中断现象Slave_SQL_Running No排查步骤查看Last_Error字段常见原因主键冲突/表结构不一致解决方法STOP SLAVE; SET GLOBAL sql_slave_skip_counter 1; START SLAVE;5.2 分库路由失效现象查询返回空但数据存在检查清单分片键值是否为NULL分片算法版本是否一致是否误用本地事务注解Transactional6. 性能优化实战技巧经过多个项目的锤炼我总结出几个关键优化点主从切换使用Orchestrator工具实现自动故障转移VIP切换时间3秒分库扩容采用双倍扩容法每次扩容新增100%容量减少数据迁移次数连接管理分库场景下使用HikariCP连接池每个物理库单独配置连接池在最近的一个物联网平台项目中通过上述优化方案我们实现了写性能提升8倍主从分离分库读QPS提升15倍读写分离缓存99.9%的查询响应时间50ms