分库分表设计：先确认业务边界，再选择分片键
分库分表设计：先确认业务边界，再选择分片键
一、分库分表不是性能优化的第一步
当单表数据量增长到千万或亿级时，分库分表常被提上日程。但它不是普通性能优化，而是会长期影响查询方式、事务边界、数据迁移和运维复杂度的架构决策。如果只是因为某几个查询慢，就直接拆表，后续很可能付出更高代价。
在决定分库分表前，应先确认是否已经做过索引优化、冷热数据归档、读写分离、缓存、SQL 改写和容量评估。只有当单库单表在容量、写入吞吐或运维窗口上接近边界，并且业务增长趋势明确时，分库分表才是合理选择。
二、分片键：决定未来查询能力
flowchart TD A[业务实体] --> B[选择分片键] B --> C[路由规则] C --> D[分库] C --> E[分表] D --> F[事务边界] E --> G[查询约束] F --> H[业务改造] G --> H分片键是最关键的设计。它应该具备高区分度、稳定性、查询高频和业务边界清晰等特点。订单系统常用用户 ID、商户 ID 或订单 ID；多租户系统常用租户 ID；日志类数据可能按时间分片。没有完美分片键，只有最适合主要访问路径的选择。
要警惕两类问题。第一是热点分片，例如少数大商户或大租户占据大量写入，导致单个分片压力过高。第二是跨分片查询，例如后台运营按时间、状态、地区组合查询，如果分片键不在条件里，就可能扫多个分片。分片方案必须和查询场景一起评审，而不是只看写入。
三、路由实现：让分片规则可测试、可迁移
下面是一个简化的分片路由示例。真实项目可以使用 ShardingSphere 或自研路由层，但规则必须可测试。
public Shard route(long userId, long orderId) { int databaseIndex = Math.floorMod(Long.hashCode(userId), 8); int tableIndex = Math.floorMod(Long.hashCode(orderId), 16); return new Shard("order_db_" + databaseIndex, "t_order_" + tableIndex); }路由规则一旦上线，迁移成本很高。因此要把规则版本化，并为历史数据保留兼容能力。扩容时不能简单把 8 个库改成 16 个库，否则旧数据路由会错。常见做法是引入逻辑分片和物理分片映射，扩容时迁移部分逻辑分片，而不是重算全部数据位置。
测试也要覆盖边界。包括同一用户订单是否路由稳定、跨月数据是否命中正确表、扩容前后路由是否兼容、批量查询是否能按分片聚合、异常分片是否能快速失败。分库分表的问题一旦进入生产，修复成本通常高于普通业务 bug。
四、事务和查询：接受约束，设计替代方案
分库分表后，跨分片事务会变复杂。不要轻易依赖分布式事务解决所有问题，尤其在高并发交易链路中。更常见的做法是通过业务幂等、状态机、最终一致性、消息补偿和对账任务来控制一致性。架构上要承认拆分后的约束，而不是假装还能像单库一样使用。
查询能力也会变化。按分片键查询通常很快，不带分片键的查询可能需要广播到多个分片。后台运营和数据分析需求可以通过搜索引擎、OLAP、数据仓库或汇总表解决，不要让在线库承担所有查询模式。
上线前必须准备数据迁移和回滚方案。迁移过程要支持双写、校验、灰度读、差异修复和切流。切换后还要观察路由错误、分片负载、慢 SQL、跨分片查询次数和数据差异。分库分表不是一次改造，而是一段较长的工程过程。
五、总结
分库分表要先确认业务容量和访问路径，再选择分片键和路由规则。它会改变事务、查询和运维方式，不应被当成普通 SQL 优化。把规则版本化、迁移方案和一致性策略设计清楚，才能让拆分后的系统可持续演进。