水平分表的路由算法：范围路由、Hash路由与配置路由的权衡

[[分表的两种方式：垂直分表与水平分表的蛋糕类比]]中的水平分表适合表行数特别大的表（有的公司把5000万行作为经验参考线，但这不是绝对标准——复杂表可能百万级就要分表，简单表即使过亿也可以不分，关键还是看表的实际访问性能，但一旦看到千万级数据量，架构师就该对潜在的性能瓶颈保持警觉）。水平分表比垂直分表复杂得多，首要难题是”路由”：某条数据具体落在哪个切分后的子表，需要一套路由算法来决定，常见有三种。范围路由选取有序的列（如自增ID、时间戳）作为分段依据，比如按用户ID每100万一段分别路由到不同库表；它的复杂点在于分段大小的取舍——分段太小会导致子表数量膨胀、维护成本上升，分段太大又可能单表依然存在性能问题（经验区间大致在100万至2000万之间），优点是能随数据增长平滑扩充新表而不用动旧数据，隐含缺点是分布可能严重不均匀（某个分段实际只存了1000条，另一个分段却存了900万条）。Hash路由选取某列（或几列组合）做哈希运算，再按哈希结果分配到不同子表，比如用user_id % 10决定落在哪张表；优点是分布相对均匀，缺点是初始表数量的选取本身就是个难题（太多难维护、太少单表性能仍不够），而且一旦要扩充表数量，几乎所有数据都要重新分布，成本很高。配置路由则是单独建一张路由表（如user_router，记录user_id到table_id的映射），优点是设计简单、扩表时只需迁移指定数据并更新路由表，非常灵活，缺点是每次访问都要多查一次路由表，会拖慢整体性能，而且如果路由表本身数据量也大到需要分库分表，就陷入了”路由表本身要用什么路由算法”的递归死循环。三种路由算法本质上是在”扩展平滑度”和”分布均匀度”之间做取舍，没有绝对最优解，需要结合具体业务的增长模式选择。

结构图：

flowchart TB
  A["水平分表的路由算法"]
  A --> B["范围路由<br/>按有序列(如ID)分段"]
  B --> B1["优点：可平滑扩充新表，旧数据不用动"]
  B --> B2["缺点：分段大小难取舍<br/>数据分布可能严重不均匀"]
  A --> C["Hash路由<br/>如user_id % N"]
  C --> C1["优点：数据分布相对均匀"]
  C --> C2["缺点：初始表数量难定<br/>扩表需所有数据重新分布"]
  A --> D["配置路由<br/>独立路由表记录映射关系"]
  D --> D1["优点：设计简单，扩表只需迁移指定数据"]
  D --> D2["缺点：每次多一次查询拖慢性能<br/>路由表自身过大又陷入路由递归难题"]