在第一篇中总结的思路，本质上没有根本解决问题，毕竟用来 辅助非分表key查询的映射表，最终 很大程度上也会面临过大问题。这篇说下另一种思路。
| order_id | user_id | xxx | yyy | zzz |
|---|---|---|---|---|
| 654321 | 33344232 | x | y | z |
假如有如上订单表，当我们按照order_id 来作为分表字段**（partion key）**时候，我们知道
- getByOrderId 场景，可以直接根据order_id计算出所在表，得到结果。
- getByUserId 场景，由于user_id 不是分表key,所以理论上user_id对应的订单(一个用户可能多个订单)，可能 会落在任何一张分表中，所以我们就需要去所有分表查询。
上面2中这种处理方式，是没有任何问题的，尽管可能有些查询是浪费的。毕竟， 我们之所以要水平分表，显然是由于单表数据量太大，带来了严重的性能问题，导致查询时间变长，这时候我们就期望让 表数据量减少来降低每次查询时间。但这时候对于非分表字段的查询来说，就变得麻烦了，每次都要去所有表查，
有没有办法减少非分表字段查询的这种盲目性呢？
当然是有的，在之前一篇文章类snowflake分布式id生成算法的一些优化点提到过一种方法，就是在生成分表key（order_id） 时候，在其某些二进制位上嵌入user_id中几位，以达到让同一个用户的订单，分库分表后落在同一个库的同一个表中。这样一来，我们对于user_id 的查询，就可以像order_id一样直接计算出所在的表了。
但遗憾是，大多数公司业务初期的工程师并不会完全考虑到这些，后期的重构优化是不可避免的，毕竟一个公司能不能活到明年都难说，更何况经验丰富的 工程师还死贵，还不如先找个外包或一两年经验的试下，看情况，能发展起来再说。这选择无可厚非， 但我依旧相信在程序员的世界里贵就是好，年龄大还在编码的越热爱编程。