背景

ShardingSphere 会通过分片键 username 用户名来确定数据在哪个库中的哪个表。所以，分库分表后，每次增删改查都需要带上分片键用户名。不然的话，查询会请求所有库的所有用户表，新增、修改和删除会直接报错

在登录功能中，用户一栏明确标出可以使用用户名、邮箱或手机号中的任意一个搭配密码进行登录。需要强调的是，在分库分表中，我们是通过用户名进行分片的。因此，如果在查询用户信息时不带用户名，将会触发读扩散问题。

由于登录时没有带用户名，导致无法确定用户的分片键，使得系统无法直接锁定用户的数据位于哪个数据库或者哪张表中。为了找到用户的数据，只能对全部的数据库和表进行扫描查询，这就造成了所谓的“读请求扩散”问题。

也就是说，原本读请求可以直接定位到某个数据库某张表，现在却要多处查询，无疑大大增加了系统的查询负载。

一旦出现了读请求扩散问题，势必会导致用户的登录请求响应时间变长，严重的话还可能造成登录超时。

为了解决这个问题，我们引入了两张路由表：用户手机号表和用户邮箱表。这些表的核心字段是手机号和邮箱，以及它们对应的用户名。通过这样的设计，我们能够在用户登录时，灵活地使用手机号、邮箱或用户名来进行认证。

什么是路由表?

在分库分表中，路由表（Routing Table）是一个用于映射用户数据在分片库和分片表中位置的特殊表。它记录了用户按照特定分片键（例如用户名、邮箱、手机号等）拆分后在哪个分片库的哪张分片表中。

路由表的存在使得系统可以根据不同的登录方式（用户名、邮箱、手机号）来准确地定位到用户数据所在的分片位置，从而能够在查询时快速找到对应的数据。

路由表的缺点

当然，路由表也不是万能的，同样存在着一些不好的点，比如：

• 查询性能：在进行用户登录或其他需要根据分片键查找数据的操作时，需要先访问路由表，根据分片键的取值范围定位到对应的分片位置，然后再去实际的分片库和分片表中查询数据。这样的查询过程会引入额外的查询开销，可能影响系统的查询性能。

• 维护成本：随着系统数据量的增加和业务发展，路由表的大小和复杂度可能会不断增加，维护路由表将会变得越来越复杂。对于大规模分库分表系统，路由表的维护成本可能会很高。