分库分表
把一张大表按规则拆到多个库或多个表，突破单库的容量、连接数与写入瓶颈。
又称分库分表Sharding数据分片
数据
两种拆分
- 垂直拆分：按业务把一张宽表拆成多张窄表（或把一个库拆成多个库），本质是职责分离。
- 水平拆分：按分片键（sharding key）把同一张表的数据行分散到多个库/表，本质是数据分散。通常说的分库分表指的是后者。
分片键是整个方案的命门
分片键决定了：
- 查询能否路由到单分片。带分片键的查询可以精确定位；不带分片键的查询要广播到所有分片再归并，代价极高。
- 数据是否倾斜。按地区分库，北上广深的库会先爆；按客户号哈希则相对均匀。
- 跨分片事务与关联。同一个客户的账户和交易如果不落在同一分片，转账和联表查询都要跨库。
实践原则：让最频繁的查询和事务都在一个分片内完成。银行场景常按客户号分片，正是为了让同一客户的所有数据同处一地。
绕不开的配套问题
| 问题 | 常见做法 |
|---|---|
| 全局唯一 ID | 号段模式、雪花算法、数据库序列 |
| 跨分片排序分页 | 各分片取回后在中间层归并，深分页代价极大 |
| 扩容迁移 | 一致性哈希 + 双写迁移，避免全量重分布 |
| 分布式事务 | 尽量避免；兜底用 Saga 或消息最终一致 |
不是银弹
分库分表会显著抬升系统的运维与开发复杂度：一次业务逻辑改动可能要在几十个分片上验证，跨分片查询要重写，数据订正要批量刷。在动它之前，先确认瓶颈真的在数据层——很多时候加索引、冷热分离、归档历史数据就能解决问题。
提及本词的文章
- 分库分表策略与热点治理从分片键选择到扩容与热点，讲清分库分表必须提前想清楚的几件事，以及银行海量账户下的真实取舍。
- 分库分表不是银弹分库分表解决的是单表容量与写入瓶颈，代价是查询能力和运维复杂度，本文记录决策顺序与实际付出的成本。
- 单元化架构：银行核心的容灾与扩展底座单元化的本质是把故障和容量都限制在单元内，本文记录单元切分、路由与跨单元处理的实践取舍。
- 开博第一篇：为什么写「追风笔记」记录我做银行系统架构这些年的思考，以及这个站点的由来。
- 关于专注分布式核心系统与银行业务，探索 AI 在银行领域的落地。