分库分表不是数据库资料里的高级名词，而是一种有成本的架构选择。做之前要先判断：当前问题是不是已经到了必须拆库的程度。
分库后读模型怎么同步
分库以后，经常会遇到一个问题：查询需要跨库聚合怎么办。
常见思路是把需要检索和展示的数据同步到读模型里，例如 Elasticsearch。
同步方式可以基于：
- binlog。
- 应用事件。
- 定时任务。
- 消息队列。
- 数据同步工具。
其中 binlog 同步比较常见，因为它能从数据库变更日志中捕获数据变化。但它也需要关注表过滤、字段映射、失败重试和数据一致性。
不要为了快而过早拆库
拆库确实可能改善某些性能问题，但它也会增加复杂度：
- 跨库查询变难。
- 事务边界变复杂。
- 后台管理要连多个库。
- 数据同步链路变长。
- 排障路径变多。
- 本地开发和部署更麻烦。
如果当前数据量、访问量和运维能力还没到瓶颈，先优化索引、SQL、缓存、读写模型和查询条件，通常更稳。
多站点场景要先做隔离字段
多站点或多租户场景里，很多查询都需要带上站点维度。
可以先确保：
- 查询条件包含站点 ID。
- 索引考虑站点 ID。
- 返回数据再做一次业务校验。
- 后台管理不能跨站误操作。
- 缓存 key 包含站点维度。
这样即使还没拆库，也能降低跨站数据混用风险。
什么时候考虑拆库
可以考虑拆库的信号包括：
- 单库写入压力明显过高。
- 单表或单库维护成本过高。
- 不同业务数据生命周期差异很大。
- 多租户隔离要求提高。
- 备份恢复窗口无法接受。
- 单库扩容已经接近边界。
这些信号需要结合指标看，不要只凭感觉。
维护建议
数据库分库分表资料可以按四类整理：
- 是否需要拆库的判断标准。
- 分库后的查询和读模型。
- binlog、消息和任务同步方案。
- 多站点或多租户隔离边界。
分库分表的核心不是“怎么拆”，而是先判断“该不该拆”。如果当前复杂度还没超过单库方案的承载范围，过早拆分反而会让系统更难维护。
正文完
