二级索引表：支撑跨分片库分页查询的定位机制

数据一旦按UID、时间、权重等维度被拆分到多个不同的库里，一个立刻会遇到的问题是：如果要按用户维度做分页查询（比如查看某个用户的第10页历史微博），系统怎么知道这一页数据到底存放在哪个具体的库里？微博Feed存储案例的解法是额外维护一套二级索引表，专门记录每个用户在每次分片切换时的发帖计数定位关系——比如记录”UID为1的用户，在2015年发的第一条帖子，是这个用户全部历史发帖里的第10条；2015年发的最后一条帖子，是这个用户全部历史发帖里的第50条”，通过这种”某个分片区间对应用户发帖总数的哪个区间”的映射，分页查询时先查这张索引表，定位到目标页码落在哪个（或哪几个）真实库里，再去对应的真实库里取出具体数据，而不需要遍历所有可能的库去逐一查找。这套机制之所以必要，是因为分片本身解决的是”数据怎么分散存储”的问题，但完全没有回答”给定一个逻辑上的查询条件（比如第几页），应该去哪个物理库里找”这个问题——二级索引表正是在分片带来的物理存储分散和用户面对的逻辑查询之间架起的一座桥，它本身也是需要被专门设计和维护的一层元数据。这提示了一条通用的架构原则：任何引入了分片/分区的存储系统，都必须同时设计一套定位机制（不管是索引表、路由规则还是元数据服务），来回答”给定一个逻辑查询，该去哪里找数据”，分片方案的完整性不能只看数据怎么切，还要看这套定位机制是否高效、是否随数据增长仍然可控。