分库分表到底咋查的？一条查询背后那些复杂流程你知道吗

（引用来源：微信公众号“程序员小灰”文章《分库分表到底咋查的？一条查询背后那些复杂流程你知道吗》）

你有没有想过，当你的应用有几亿用户，数据多到一台数据库服务器根本存不下也忙不过来的时候，该怎么办？这时候，高手们就会用上一个“大招”——分库分表，简单说，就是把一个超级大的数据库，像切蛋糕一样，分成很多个小块,然后把这些小块分散到不同的服务器上去。

你有一个“用户表”，里面有10亿条用户数据，一台机器扛不住，咋办？我们可以按用户ID的最后一位数字来分，尾号是0的用户数据放到第一个数据库的user_0表里，尾号是1的放到第二个数据库的user_1表里，以此类推，这样，每个小表可能就只有1000万数据了，每台数据库服务器的压力就小了很多,这就是分库分表的基本思路。

问题来了，以前你查一个用户信息，只需要简单的一句SQL：SELECT * FROM user WHERE user_id = 123456，数据库吭哧吭哧找一会儿就把结果给你了，现在可好，数据被分散到了10个甚至100个不同的数据库和表里，你知道你要找的user_id=123456这个用户，到底藏在哪一台服务器的哪一个表里面吗？这条看似简单的查询语句，背后其实经历了一场复杂的“寻宝之旅”。

这场寻宝之旅的“总指挥”，通常是一个叫做“数据库中间件”的家伙，它就像一个超级聪明的路由器，你的应用程序不再直接连接数据库，而是把所有数据库请求都发给这个中间件,复杂的事情就交给它了。

第一步：解析SQL，确定要找谁。 中间件拿到你的SELECT * FROM user WHERE user_id = 123456这条SQL后，它不像数据库那样急着执行，而是先当一回“语文老师”，仔细分析这句话的语法，它要搞清楚：你要查的是哪张表（user）？查询条件是什么（user_id = 123456）？哦,原来你是想找一个ID是123456的用户。

第二步：根据分片规则，定位目标（寻宝图）。 这是最核心的一步，中间件手里有一张“寻宝图”，也就是我们事先设定好的“分片规则”，我们刚才举的例子是按用户ID尾号分，这就是一种最简单的分片规则，中间件会拿着查询条件里的那个值——123456，套用这个规则进行计算：123456的尾数是6，好了，寻宝图显示，尾号是6的数据，存放在编号为DB_06的数据库服务器上,具体的表名是user_6。

如果查询条件更复杂，比如你要查一批用户user_id IN (123456, 789012, 345678)，中间件就得为每一个ID都计算一遍它应该去哪个库哪个表，可能会得出需要同时查询DB_06、DB_02、DB_08三个库的结果。

第三步：重写SQL，精准出击。 光知道去哪个库还不行，SQL语句也得改，原来的语句是SELECT * FROM user，但实际的目标表名是user_6，中间件会把SQL语句“重写”成：SELECT * FROM user_6 WHERE user_id = 123456，这样,语句到了具体的数据库上才能被正确执行。

第四步：路由与执行（分头行动）。 中间件现在就是一个调度员，它根据第二步计算出的结果，找到DB_06这台数据库服务器的地址，然后建立连接,把重写好的SQL语句发过去执行。

第五步：汇总结果（凯旋而归）。 DB_06服务器执行查询，找到了user_id=123456的用户数据，然后把这个结果返回给中间件，中间件拿到结果后，再原封不动地返回给你的应用程序，你的应用程序感觉就像在查询一个单一的数据库一样,完全不知道背后已经发生了这么多事情。

这还只是最简单的“等值查询”的情况，如果查询条件更复杂，比如你要进行范围查询（查ID大于1000000的所有用户）、排序、分页，或者根本没有带分片键user_id（比如按昵称模糊查询），那流程会更加复杂，中间件可能需要对所有分库分表都发起一次查询，然后把每个节点返回的结果在内存里进行汇总、排序、合并，最后再给你一个完整的结果,这个过程的网络开销和计算开销都会大得多。

分库分表虽然解决了大数据量的存储和性能问题，但它绝不是免费的午餐，它极大地增加了系统的复杂性，尤其是在查询方面，以前数据库自己就能搞定的事情，现在需要中间件和应用程序协同合作，经过解析、分片、路由、汇总等一系列步骤才能完成，了解了这条查询背后的复杂流程，你就能明白为什么数据库设计要尽量避免过度分片,以及为什么查询条件尽量要带上分片键是如此重要了。