分库分表设计先确认业务边界再选择分片键一、分库分表不是性能优化的第一步当单表数据量增长到千万或亿级时分库分表常被提上日程。但它不是普通性能优化而是会长期影响查询方式、事务边界、数据迁移和运维复杂度的架构决策。如果只是因为某几个查询慢就直接拆表后续很可能付出更高代价。在决定分库分表前应先确认是否已经做过索引优化、冷热数据归档、读写分离、缓存、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 优化。把规则版本化、迁移方案和一致性策略设计清楚才能让拆分后的系统可持续演进。