分库分表怎么做？分片键怎么选？会带来哪些问题？

详细解析#

什么时候需要拆，拆之前先试什么#

需要拆的信号：

• 写入瓶颈：单主库的写 TPS、连接数或磁盘 I/O 到顶，读写分离只能分担读，解决不了写
• 数据量太大：热数据放不进 Buffer Pool，查询频繁读磁盘；加字段、加索引、备份恢复的耗时让人无法接受
• 容量：数据量接近单机磁盘的上限

常听到的"单表超过 2000 万行就要拆"，通常的解释是 3 层 B+ 树的估算（见 B+ 树）：假设每行 1KB，3 层大约能放 2000 万行，再多就要 4 层。但上层节点一般都缓存在 Buffer Pool 里，多一层只是多一次查找，性能不会在某个行数突然下降。各种行数阈值都只是特定表结构和硬件下的经验值，真正的依据是监控指标和业务增长预期。

拆之前先试成本低的办法：

1. SQL 和索引优化，见 慢查询怎么优化
2. 加缓存挡住读流量，见 缓存一致性
3. 读写分离，用从库分担读，见 主从复制
4. 历史数据归档：订单只在线保留近一两年，更早的迁到归档库或数据仓库
5. 升级硬件，或者用分区表：分区表还在一个实例里，对应用透明，但解决不了单机瓶颈

垂直拆分和水平拆分#

垂直拆分是业务层面的边界划分，一般先做；水平拆分才是真正的"分片"。只分表不分库，所有表还在一台机器上，解决不了单机瓶颈。

分片策略#

哈希取模常和预分片一起用：一开始就分成足够多的逻辑分片（比如 32 张表），初期放在少数几台机器上，扩容时只是把整张表搬到新机器，不用重新计算每一行的位置。按节点数取模的扩容问题，也可以用 一致性哈希 缓解。

分片键怎么选#

• 查询最常带的条件：订单最常按用户查，按 user_id 分片，查"我的订单"只访问一个分片；不带分片键的查询只能广播到所有分片
• 分布均匀：避免数据和流量倾斜。按商家分片时，一个大商家可能占掉一半订单
• 不会变：分片键一改，数据就要搬到别的分片
• 让事务尽量落在一个分片内：同一个用户的订单和订单明细用同一个分片键，事务就不用跨库

另一个维度也要查时，比如商家查自己的订单：可以按 seller_id 再冗余一份数据，通过订阅 binlog 异步同步（见 binlog 的其他用途）；复杂的多条件搜索交给 Elasticsearch。按订单号查订单可以用基因法：生成订单号时把 user_id 的低几位嵌进去，订单号和用户 ID 就能路由到同一个分片，见下面的代码。

拆分带来的问题#

用什么实现#

• 客户端分片：如 ShardingSphere-JDBC，以 jar 包形式嵌在 Java 应用里，没有额外的网络跳转，但只能用于 JVM 上的应用
• 代理分片：如 ShardingSphere-Proxy、Vitess，应用像连普通 MySQL 一样连代理，语言无关，但多一跳网络，代理本身要做高可用
• 分布式数据库：如 TiDB，兼容 MySQL 协议，数据按范围切成 Region 自动分布和调度，自带分布式事务，应用基本不用关心分片，代价是要接受和 MySQL 不同的性能特征和运维体系

代码示例#

4 个库、每库 8 张表，按 user_id 路由，订单号用基因法（Node.js）：

const DB_COUNT = 4
const TABLES_PER_DB = 8
const SLOTS = DB_COUNT * TABLES_PER_DB // 32 张分表，取 2 的幂，方便基因法
const GENE_BITS = 5n // 32 = 2^5，取 ID 的低 5 位做"基因"

// 先算落在第几张表，再算这张表在哪个库
// id 可以传字符串或 BigInt，超过 2^53 的 ID 不能用 Number 传，会丢精度
function route(id) {
  const slot = Number(BigInt(id) % BigInt(SLOTS))
  return {
    db: `order_db_${Math.floor(slot / TABLES_PER_DB)}`,
    table: `t_order_${slot % TABLES_PER_DB}`,
  }
}

// seq 来自号段这类发号器；订单号的低 5 位直接取自 user_id
// seq 要小于 2^58，左移 5 位后才不会超出 BIGINT 的范围
function genOrderId(seq, userId) {
  const gene = BigInt(userId) & ((1n << GENE_BITS) - 1n)
  return (BigInt(seq) << GENE_BITS) | gene
}

route(1001) // { db: 'order_db_1', table: 't_order_1' }
route(genOrderId(123456789, 1001)) // 同上，按订单号也能找到同一张表

订单号的低 5 位和 user_id 相同，所以两者对 32 取模的结果一样。前提是分片数是 2 的幂，并且基因位数要按将来可能扩到的分片数预留。

面试官可能追问#

易错点#

• 只分表不分库，解决的是单表太大的问题，解决不了单机的写入和容量瓶颈
• 分片键选错的代价很大，事后更换基本等于把所有数据重新迁移一遍
• 跨分片分页时，偏移量越大，每个分片要多返回的行越多，深分页的问题会成倍放大
• "单表多少行就要拆"的数字都是经验值，判断要看监控指标和增长趋势