分库分表的常见策略包括垂直分库、水平分表、水平分库及组合使用；选择分片键需考虑查询命中、数据倾斜和扩容便利；查询问题可通过强制路由、广播查询、中间件支持等方式解决；扩容则分为停服和在线迁移两种方式。具体来说：1. 垂直分库按业务拆分，水平分表按规则拆分单表，水平分库将表分散到多个数据库，组合使用可兼顾两者优势；2. 分片键优先选用户id、时间或地域，需避免跨分片查询、热点数据和扩容困难；3. 查询问题通过强制路由定位分片、广播查询合并结果、引入中间件处理复杂sql或冗余字段设计来应对；4. 扩容可选择停服简单迁移或在线迁移，后者包括准备新结构、迁移数据、同步增量、切换流量并验证一致性。
在大数据量场景下，MySQL 的性能瓶颈往往会暴露出来，尤其是单表数据量超过千万级甚至更高时，查询、写入、锁竞争等问题都会变得明显。这时候分库分表就成了常见的解决方案。
分库分表的常见策略
分库分表的核心目标是降低单点压力，提高系统可扩展性。常见的策略包括：
- 垂直分库：按业务模块拆分数据库，比如用户相关的放在 user_db，订单相关的放在 order_db。
- 水平分表：将一张大表按一定规则拆分成多个小表，比如按用户ID取模。
- 水平分库：把同一张表的数据分散到多个数据库中，例如 db0.user_0 和 db1.user_0。
- 组合使用：垂直和水平结合，比如先按业务分库，再在每个库内进行水平分表。
选择哪种方式，主要看你的业务特点和增长预期。
如何选择分片键（Sharding Key）
分片键决定了数据如何分布，是非常关键的一环。选不好会导致数据倾斜、查询效率低等问题。
常见的分片键有：
- 用户ID（适用于大部分面向用户的系统）
- 时间字段（如订单创建时间，适合按月或年归档）
- 地域信息（如城市、区域，适合本地化服务）
选分片键时要注意以下几点：
- 尽量保证查询能命中一个分片，避免跨库/跨表查询
- 避免热点数据集中在某个分片上
- 考虑未来扩容是否方便，比如取模就不容易扩容，而一致性哈希或者范围分片更灵活
举个例子，如果你用用户ID做分片键，那么所有与该用户有关的操作都可以落在一个分片上；但如果经常需要跨用户统计，那可能就需要额外处理了。
分库分表后的查询问题怎么解决
分库分表之后，原来简单的 SQL 可能不能直接用了，尤其是涉及聚合、排序、关联等操作的时候。
一些常见的应对方式：
- 强制路由：根据分片键直接定位到具体分片执行查询
- 广播查询：在所有分片上执行相同语句，然后合并结果（适合读多写少、数据量不大的场景）
- 中间件支持：比如 MyCat、ShardingSphere 等，可以自动帮你做路由、合并、排序等
- 冗余设计：对常用聚合查询字段进行冗余存储，避免跨分片计算
需要注意的是，跨分片的 JOIN 操作代价很高，应尽量避免，可以通过应用层拼接数据，或者通过异步同步的方式整合到单独的查询表中。
数据扩容与迁移怎么做
随着数据量增长，你可能会面临扩容的问题。比如原来的 4 个分片不够用了，要扩展成 8 个。
扩容方案大致分为：
- 停服扩容：简单但影响用户体验，适合早期阶段
- 在线扩容：通过中间件或代理实现不停机迁移，适合线上服务
迁移过程一般包括：
- 准备新分片结构
- 全量迁移历史数据
- 同步增量数据（比如通过 binlog 或消息队列）
- 切换流量到新分片
- 观察并验证数据一致性
这个过程中最怕的就是数据不一致或者切换失败，所以一定要做好回滚准备和监控机制。
基本上就这些。分库分表不是一上来就要做的，而是当系统发展到一定阶段、单机性能撑不住时才考虑。设计时要考虑好未来的扩展性和维护成本，别为了分而分。
