数据库拆分的需求往往出现在一种尴尬的境况——当你发现单表行数突破亿级，索引开始肿胀，查询像在泥浆里游泳。最初你以为只是索引设计不当，直到发现连主键查找都慢得离谱。那感觉，大概就像试图在图书馆里找一本没有被索引的书。于是你考虑Sharding。
其实很多人在这一步就搞错了方向。Sharding不是简单的把表切成几块，它是把数据分布在多个节点上，让每个节点只处理一部分行。而实现的关键，在于路由逻辑——也就是你要在查询前知道数据落在哪个片里。算法层面上，常见的有哈希取模、一致性哈希、范围分片。但背后真正保证可扩展性的，不是算法本身，而是数据分布的均匀度和迁移成本。一致性哈希加虚拟节点，这个方案在工程上近乎完美：节点增删时只需移动极少量的数据，而且能保证分布足够均匀。记得有一次我手动测试，在10节点集群里加一台新机器，使用一致性哈希，需要迁移的数据量只有总数据的9.3%，而传统取模方式要迁移近45%。差距惊人。
这里插一句——很多人误以为分片键必须和主键强绑定，其实完全没必要。你完全可以给每个表指定一个sharding key，只要业务查询大都携带这个key，就能精准路由。比如在订单系统里，user_id显然比order_id更适合做分片键，因为大部分查询是按用户维度的。但这里有个坑：如果你的sharding key选择导致热点分布严重不均，比如大V用户有海量订单，那部分片就会过载。这种时候需要二级映射或细粒度的子分片，我通常用一致性哈希＋预分桶的策略，将热点用户路由到独立桶，再映射到物理节点。
这些原理说起来抽象，其实拿数据库做个比喻就清晰了：B+树索引在一张表里就像一本书的目录，而Sharding相当于把这本书拆成多个分册，每个分册有自己的目录。当你按user_id查订单时，你只需要知道该翻哪本册子，而不是把所有册子的目录都扫一遍。这里有个关键概念是“分片键选择性”——如果查询不带分片键，就会退化为全分片扫描，这时性能比不拆分还糟。
我们实际压测过一套方案：12个物理分片，每个分片独立MySQL实例，使用ProxySQL做中间件，规则基于用户ID取模。单表大约2.4亿行，未分片时，按user_id查询平均耗时380ms，分片后落到单片的查询平均仅8ms，吞吐量从230 QPS提升到3100 QPS。但全分片扫描的查询（比如按订单状态分页）耗时却上升到1.8秒。这就是为什么必须在设计之初就核算查询模式。数据不会说谎，拆分后的收益和代价透明得像玻璃。
落地过程里有三个点让我栽过跟头。
第一个，跨分片事务。千万别信那些说Sharding后还能完美支持ACID的鬼话。分布式事务的方案无非是两阶段提交或者最终一致性。两阶段提交，那个性能衰退——我在一次压力测试中看到，引入XA事务后，TPS从1200直降到180。所以现实方案只能是：尽可能避免跨分片操作，或者用本地事务+补偿机制。我们在用户余额扣减场景里，采用本地事务先扣钱，再异步通知其他服务，失败则重试和反向操作。最终一致性，业务上得接受。
第二个，扩容再平衡。当你发现容量不够要加节点，数据迁移就成了噩梦。现网不停机迁移尤其麻烦。我们用过一套方案：双写过渡。先保持旧分片规则不变，新数据同时写入旧规则和新规则的分片，后台用低峰期慢慢搬运历史数据，最后切换路由。听起来简单？那次搬运时数据不一致，因为搬运过程中有更新操作落在了只被搬运了一部分的片。我们后来加了严格的搬运窗口锁和版本号比对，才勉强搞定。整个迁移持续了将近两周，所以千万别等到极限才扩容。
第三个，查询层面的坑。分片后，排序、分页、聚合都变得棘手。跨分片排序你没法指望数据库，必须在中间件层做归并。比如要按时间倒序取前100条，你得在每个分片取前100条，然后归并排序再取前100。当页数较深时，这个开销会成倍放大。我们用Limit 10000, 100这种深分页测试，分片数越多性能越差。最后我们只能在业务层做限制，禁止过深分页，并拿Elasticsearch做搜索侧兜底。
说到工程美学，我偏爱那种极简的拆分架构：计算层与存储层彻底解耦，分片逻辑全部放在无状态的查询路由器里，下面挂载多个同构的存储节点。这种架构可以在不改变任何存储模型的情况下，实现近乎线性的扩展。就像乐高积木，要增加容量，只需插入新块。我们曾经把一个2.7TB的数据库拆分成16个分片，集群处理能力从4000 QPS翻到58000 QPS，延迟中位数从200ms降到6ms。在监控屏上看到那条线瞬间跳水的时候，你会有一种奇特的舒畅感。
再谈谈协议层。有些中间件在协议解析上偷懒，只是简单代理，结果导致连接数爆炸。真正的优雅是在二进制协议层面解析MySQL packet，实现连接复用和状态保持。像ShardingSphere-Proxy，它在Netty基础上做了事件驱动的MySQL协议实现，每个分片维持少量长连接，复用度极高。我在一次演讲里画过它的线程模型：前端并发一万条连接，后端只占用不到两百个连接。这就是工程优化的魅力——你只是在代码里动了几个数据结构，但给整个集群注入了生命力。
哦对了，还有个细节。分片算法要支持无状态路由，千万别用中心化元数据去查路由，否则那个元数据中心会成为新的瓶颈。我们一开始用ZooKeeper存分片映射，发现高并发下ZooKeeper延迟不时抖动，后来干脆硬件编码了分片规则，牺牲灵活性换取确定性。极端场景下，确定性比灵活性重要得多。
文章写到这儿，其实我还没提Sharding和微服务的纠缠——有时候按业务垂直拆分反而更暴力有效，但那又是另一个话题了。分片是技术活，更是平衡术。
最后放两张图，也许更能说明问题。
这是逻辑架构，下面这种底层协议交互其实更有意思。
所以每当有人问起Sharding是不是过时了，我只想说：工具永远不会过时，过时的是不懂权衡的头脑。
