分库分表与读写分离是互补的扩展手段：前者按业务（垂直）或数据特征（水平）拆分以缓解容量和写压力，后者通过主从分流提升读并发；二者应分层组合使用，先分库分表再在各分片内配置读写分离，并配套监控、分片键评估等关键措施。
当单库单表性能遇到瓶颈，分库分表和读写分离是两种主流、互补的扩展手段。选对策略比盲目拆分更重要——分库分表解决容量与并发写压力，读写分离缓解查询负载，二者常组合使用，但需配合业务特点设计。
分库分表：按数据维度切分，突破单机瓶颈
核心是把原本集中在一台数据库上的数据，按一定规则分散到多个库或多个表中，从而提升整体吞吐和存储能力。
- 垂直拆分：按业务逻辑拆，比如用户信息、订单、商品分别放入 user_db、order_db、product_db。适合模块边界清晰、耦合度低的系统。
- 水平拆分：按数据特征（如 user_id、order_no）取模、范围或一致性哈希，把同一类表的数据打散到多个库/表。例如 user 表按 user_id % 4 拆成 4 张子表，分布在不同实例上。
- 实际落地要注意：跨库 JOIN、分布式事务、全局唯一 ID、分页排序等会变复杂，建议用 ShardingSphere 或 MyCat 等中间件屏蔽部分复杂性。
读写分离：主从架构下的流量分流
基于数据库原生主从复制机制，写操作走主库（Master），读操作路由到一个或多个从库（Slave），降低主库查询压力，提升读并发能力。
- 适用于读多写少场景（如内容平台、电商详情页），读请求可自动负载到多个从库，主库专注写入与同步。
- 需注意主从延迟：从库可能滞后几毫秒到几秒，对强一致性读（如刚下单查订单）应强制走主库，可通过 Hint 或注解标记“主库读”。
- 常见实现方式包括应用层路由（Spring Boot + AbstractRoutingDataSource）、代理层（MaxScale、ProxySQL）或驱动层（MySQL Connector/J 的 loadBalance 配置）。
怎么组合用才不踩坑？
分库分表和读写分离不是二选一，而是分层协作：先分库分表解决单库容量和写瓶颈，再在每个分片内配置主从读写分离提升读能力。
- 例如：将订单库水平拆为 order_db_0 ~ order_db_3，每个库内部设 1 主 2 从，写入固定发往主节点，普通列表查询随机打到任一从节点。
- 务必避免“过度设计”：小流量业务强行分库分表反而增加运维和开发成本；没有监控就上读写分离，可能因延迟引发数据不一致问题。
- 关键配套不能少：全链路慢 SQL 监控、分片键选择合理性评估、从库健康检查与自动摘除、以及回滚方案（比如某分片异常时能否临时切回单库模式）。
不复杂但容易忽略。策略本身成熟，成败取决于是否贴合业务增长节奏和团队技术水位。
