分片深入:分片键与跨片查询

很多团队聊到"数据库扛不住了",第一反应就是"上分片"。但分片从来不是"把数据均匀拆开就万事大吉"——它真正的难点不在拆,而在拆完之后怎么查。决定这一切的,是一根贯穿全局的命脉:分片键。

这篇文章不讲"分片是什么",而是讲那些真正上线后才会痛到的细节:分片键怎么选、跨片查询怎么扛、全局 ID 怎么发,以及为什么我对绝大多数项目的建议是——先别分片。

一、分片键是分片的命脉

分片键(Shard Key)是决定一行数据落到哪个分片的那一列。它一旦选定,几乎决定了这个系统此后所有的查询形态、扩展能力、热点分布。

为什么说它"选错 = 查询全扫 + 数据倾斜"?因为分片之后的查询路由逻辑是:

SELECT * FROM orders WHERE user_id = 123;
-- 中间件:hash(123) % N → 命中第 3 号分片 → 只查这一片

只要 WHERE 里带了分片键,中间件就能精确定位到单一分片,代价和单机一样;但只要没带分片键,中间件就只能把这条 SQL 广播到所有 N 个分片,各片各查各的,再把结果合并。这就是臭名昭著的"scatter-gather"——一次查询变成 N 次查询,延迟翻 N 倍,连接池被打爆。

而"数据倾斜"更隐蔽。如果你选了一个分布不均的键(比如按"城市"分片,北上广深那几个片会爆,西藏青海那几个片空着),所谓"水平扩展"就成了一句空话——热点分片撑爆,冷分片闲置,加多少节点都救不了。

所以记住一句话:分片键不是"选一个能拆数据的列",而是"选那个让绝大多数查询都能精准路由、且数据分布均匀的列"。这是一道权衡题,没有标准答案,只有"最适合你业务读写模式"的答案。

二、分片键设计的三条铁律

实战中,我评估一个分片键通常看三条:

1. 高基数(均匀分布)。候选列的取值要足够多、足够分散,hash 之后才能均匀落到各分片。user_id、order_id 这类主键天然高基数;而 gender(只有 M/F)、status(几个枚举值)、country(几十个)就是灾难——它们会让某些分片严重超载。低基数列永远不能单独做分片键。

2. 查询路由(WHERE 常带分片键)。理想的分片键,应该出现在 95% 以上的查询 WHERE 子句里。做 ToC 业务,绝大多数查询都是"某用户的订单/消息/动态",user_id 自然是首选;做 SaaS 多租户,所有查询都带 tenant_id,它就是天选。反之,如果你选 order_id 做分片键,但查询经常要"按用户列订单",那绝大多数查询都会退化为广播。

3. 避免热点(单调递增的列要小心)。自增 ID、时间戳做分片键,看似均匀,实则后患无穷:所有新写入都集中在"最后一片"(因为 ID/时间单调增大),那一片永远是写入热点,其他片闲死。这就是为什么用时间戳直接分片几乎一定是错的——你需要对它做 hash 或加随机前缀打散。

-- 反面教材:按自增 id 分片 → 新数据永远落在最后一片
SHARD KEY: id (auto_increment)

-- 正面:按 user_id 分片,用户写入天然分散
SHARD KEY: user_id

三、常见的分片键选型

实战中我见过、用过的几种典型选型:

• user_id(C 端业务的默认选择)。电商订单、IM 消息、社媒动态,查询几乎都是"按用户维度",user_id 既高基数又常带在 WHERE 里。代价是:跨用户的统计查询(比如"昨日全网 GMV")会变成跨片聚合,需要专门处理。

• tenant_id(多租户 SaaS 的标准答案)。每个客户的数据天然隔离,租户内查询全部命中单片。但要警惕"超大租户"——某个大客户的量级可能超过单片容量,需要再叠加一层 sub_id 复合分片。

• hash(id) / hash(some_key)。均匀性最好,但没有业务语义——任何按业务字段的查询都会退化为广播。通常只在"存的是纯 KV、永远只按 id 查"的场景(比如用户头像、文件元数据)才合适。

• 复合分片键(如 tenant_id + user_id)。先按租户路由到分片组,再在组内按用户二次拆分。这是处理"租户间数据量差异巨大"的标准手法。

一句话总结:跟着查询走,别跟数据走。先把你最频繁的 10 条 SQL 列出来,看它们 WHERE 里共同带的是哪一列,那一列大概率就是你的分片键。

四、跨片查询的四种噩梦

分片键选对了,90% 的查询能精准路由;但剩下那 10% 的跨片查询,会把你折磨到怀疑人生。主要有四种:

1. 跨片 JOIN(几乎不可做)。分片之间是物理隔离的独立数据库,你没法在它们之间做 SQL 的 JOIN。一个"订单表(按 user_id 分片)"和"商品表(按 product_id 分片)",JOIN 的时候根本不知道该往哪发。常见的应对是:应用层合并——分别查两片,在内存里用 hash map 做关联;或者干脆反范式化,把商品名称冗余存进订单表。

2. 跨片聚合(COUNT/SUM/MAX)。SELECT COUNT(*) FROM orders 会广播到所有片,每片返回一个 count,应用层把它们加起来。简单聚合还好,复杂的(比如 COUNT(DISTINCT user_id))就极难——你不能把各片的 distinct 结果简单相加,因为同一个 user 可能存在于多个片。这类查询通常得靠预聚合表或离线数仓。

3. 跨片分页(全局 LIMIT/OFFSET 是地狱)。ORDER BY created_at LIMIT 10 OFFSET 1000 看起来无害,但分片后要做"全局第 1001~1010 条",你必须从每片都取前 1010 条(共 N×1010 条),在应用层全局归并排序后再切片。OFFSET 越大,代价越大,深分页直接 OOM。常见解法是用游标(keyset pagination)替代 OFFSET,或者干脆只允许按分片键分页(每个用户自己的订单分页,永远在单片)。

4. 跨片 DISTINCT(几乎无解)。跨片的去重在分布式下没有银弹,通常要么接受近似值(HyperLogLog),要么完全避免这种查询。

五、跨片查询的三大应对策略

既然跨片查询这么痛,工程上一般用三招:

1. 反范式化(冗余存储)。把高频 JOIN 的字段冗余进主表——订单表里直接存 product_name、user_name,省掉跨片 JOIN。代价是更新成本(商品改名要同步刷所有订单),但对读多写少的场景极其划算。这是分片系统里最常用的一招。

2. CQRS(读写分离模型)。写库按分片键拆分保证写入吞吐;读侧用专门的索引服务、物化视图、Elasticsearch、列式存储(ClickHouse)来服务复杂查询。写库和读库各做各的擅长事,通过 binlog/CDC 同步。这是大型系统处理"既要按用户写、又要按各种维度查"的标准架构。

3. 限制跨片查询(API 层约束)。最朴素也最有效——直接在产品层面禁止跨片查询。后台管理界面要求必须先选用户、再查订单;统计报表走 T+1 的离线数仓,不直接打在线库。承认分片的局限,用产品策略绕过去,而不是硬刚。

六、全局唯一 ID:自增已死,雪花当立

单机时代的 AUTO_INCREMENT 在分片后彻底失效——每个分片独立计数,主键必然冲突。所以分片系统必须有一套全局唯一 ID 方案。

主流选择有两个:

雪花算法(Snowflake)。64 位整数 = 时间戳(41bit)+ 机器 ID(10bit)+ 序列号(12bit)。趋势递增(方便 B+ 树插入)、分布式无冲突、本地生成无网络开销,是工业界事实标准。要点是机器 ID 分配要有管控(配置中心或 ZooKeeper),否则两台机器同 ID 就会冲突。很多公司会在雪花基础上改造成 64bit 字符串、加上业务前缀。

UUID。彻底无中心、生成零成本,但有两个硬伤:完全无序(B+ 树插入时页分裂严重,写性能差)、占用空间大(128bit vs 64bit)。所以 UUID 几乎从不用于数据库主键,更多用于业务层的资源标识(文件 ID、会话 ID)。

此外还有 DB 号段、Redis INCR 等中心化方案——简单但有单点和性能瓶颈。对绝大多数分片系统,雪花(或其变种)是最佳默认选择。

七、一致性哈希:动态扩缩容的关键

"数据怎么路由到分片"也有讲究。最朴素的是 hash(key) % N(N 是分片数),简单但有个致命问题:N 一变,几乎所有数据都要重新迁移。从 4 片扩到 5 片,约 80% 的 key 要搬家——这在线上几乎是不可接受的开销。

一致性哈希(Consistent Hashing) 解决的就是这个问题。把哈希空间组织成一个环,节点和 key 都映射到环上,key 顺时针找到的第一个节点就是它的归属。这样加减一个节点,只影响环上相邻那一段 key,迁移量约 1/N,而不是全量。配合虚拟节点(每个物理节点映射 100~200 个虚拟节点)还能解决数据倾斜。

实战中,Vitess、Cassandra、Redis Cluster、MongoDB Sharding 都用了一致性哈希或其变体。但凡系统需要动态扩缩容,一致性哈希都是必选项。 当然,如果你能做到"一次性规划好分片数(比如 1024 个虚拟分片,初期映射到 4 个物理库),以后只改映射不改分片数",那取模也够用——这是工程上常见的"预分片"手法。

八、现实建议:90% 的项目先别分片

讲了这么多分片的硬骨头,我要泼一盆冷水:绝大多数项目根本不需要分片。

真实的容量天花板远比你想的高。一台现代数据库服务器,主从分离 + 合理索引 + 表分区(Partition)+ Redis 缓存,TB 级数据、几万 QPS 完全 hold 得住。绝大多数"数据库慢"的根因是——索引烂、SQL 烂、N+1 查询、缺缓存、热表没分区——这些都是单机就能治的病,跟分片没关系。

而分片的代价是巨大的:

• 运维复杂度暴涨:备份恢复、DDL 变更、Schema 演进、跨片事务,每一项都是 distributed hell。
• 业务约束变硬:不能随便加 JOIN、不能随便改分片键、跨片事务几乎不可用。
• 一旦分了,几乎回不去:分片键改不动,数据迁移极难,架构锁定。

我的实战建议是:先把单机榨干(读写分离、垂直拆分按业务分库、热点表分区、上缓存、优化 SQL 和索引),只有当你写量或数据量确实超过单机物理上限、且未来 2~3 年还会持续增长时,才考虑分片。而且优先按业务垂直拆分(订单库、用户库、商品库分开),水平分片永远放在最后。

记住一句话:分片不是优化手段,是认输后的兜底。当你开始分片,你是在向"单机关系型数据库的能力上限"低头,从此就要接受分布式系统所有的复杂度。

小结

• 分片键是命脉:决定查询路由和数据分布,选错则查询全广播、数据全倾斜。三条铁律——高基数、查询常带、避免单调热点。
• 选型跟着查询走:C 端选 user_id,SaaS 选 tenant_id,纯 KV 选 hash(id),超大租户用复合键。
• 跨片是噩梦:JOIN(应用层合并/反范式)、聚合(预聚合表/数仓)、分页(游标替代 OFFSET)、DISTINCT(近似或禁止)。
• 配套工程:全局唯一 ID(雪花为主)、一致性哈希(动态扩缩容)、CQRS(读写分离模型)、预分片(规划好分片数)。
• 现实建议:90% 项目先别分片,单机+读写分离+分区+缓存通常够用;分片是兜底,不是优化,且一旦分了几乎无法回退。

金句:分片键不是"选一个能拆数据的列",而是"选那个让绝大多数查询都能精准路由、且数据分布均匀的列"。而分片本身,不是优化手段,是认输后的兜底——开始之前,先把单机榨干。