一个挺着啤酒肚，身穿格子衫，发际线重大后移的中年男子，手拿着保温杯，胳膊夹着 MacBook 向你走来，看样子是架构师级别。
面试开始，直入正题。
面试官：小伙子，看到你的简历下面写了我的项目中有对 MySQL 进行分库分表，为什么要进行分库分表？
我：不晓得啊！谁晓得老大咋想的，反正我来的时候就曾经分好了。
面试官：嗯 …，明天的面试就先到这吧，有后续面试会告诉你，我送你上来。
别啊，每次都说会告诉我，而后我就傻傻的回去等告诉了。我是实话实说，难道让我去订阅一灯的文章，背诵八股文给你听？
好吧！自古真情留不住，总是套路得人心。重来一次，我把一灯总结的八股文背诵一遍。
我：当 MySQL 单表数据量过大，比方超过 5 千万条的时候，读写性能变得很差。而且惯例的优化伎俩曾经不起作用了，比方：SQL 调优、增加索引、主从复制、读写拆散。这时候就须要用到 MySQL 终极优化计划 — 分库分表。
面试官：不错，我该怎么判断我的项目是须要分库还是要分表？是先分库还是先分表？
这谁能现场总结进去？别着急，等我看一眼一灯的八股文。
我：有了。
- 当数据库的 QPS 过高，数据库连接数有余的时候，就须要分库。
- 当单表数据量过大，读写性能较差，就须要分表。
- 当两者都有的时候，就须要分库分表。
至于先分库还是先分表？倡议先分表，如果分表能解决问题，就不须要分库了，毕竟须要独自服务器资源，老本更高。
面试官：小伙子，总结的挺全。分库分表有哪些拆分计划呢？
我：分库分表有垂直拆分和程度拆分。垂直拆分又有垂直分库、垂直分表。
垂直分库，不同的业务拆分到不同的数据库。
垂直分表，把长度较大或者拜访频次较低的字段，拆分到扩大表中。
程度分表，单表数据量过大时，依照订单 ID 拆分到多张表中。
面试官：小伙子，有点货色。都晓得分库分表好使，就没有什么毛病吗？
我：当然有，“所有命运馈赠的礼物，早已在暗中标好了价格。”分库分表带来了低耦合、高性能的长处，可是毛病却是一大堆。
垂直分库：
不同库多表之间无奈 join 关联查问，只能通过接口聚合，复杂度直线回升。
横跨多个数据库导致无奈应用本地事务，数据强一致性就别想了，只能引入更为简单的分布式事务，勉强实现数据的最终一致性，可用性直线降落。
垂直分表：
原本一张表能查出来的数据，当初须要多张表 join 关联查问，这不瞎耽搁事。
程度分表：
多张表关联查问时，无奈实现分页、排序功能。
面试官：分库分表带来这么多问题，你没有没思考过相应的解决方案？
我怎么可能没有解决方案，难道我提出问题给本人挖坑？
我：当然有思考过，“有问题就会有答案”。
跨库查问问题：
采纳 字段冗余 计划，比方订单表存储店铺 ID、店铺名称，就不须要再查问商户数据库了。
不过这种计划要求冗余字段要很少变动，就算变动后，也能容忍返回旧数据。
多表分页查问问题：
这个解决起来就很须要技术含量了。
比方：订单表依照订单 ID 分片，(order_id % 128)，分成了 128 张表。
Leader 看了说：每张表的数据量差不多，分的很平均，当前不要再分了。
同一个用户的订单散落在不同的表，用户想查问本人的订单，根本无法做到分页查问。难道一次全副查问该用户的所有订单，而后做内存分页，多大的机器内存都让你搞挂。
想要实现用户订单分页查问，能够采纳依照用户 ID 分片，(user_id % 128)，这样同一个用户的订单只会存储在一张表中，咋分页展现都行。
没有完满的分片计划，如果商户想要分页查看本人店铺的订单怎么办？
那就把订单再冗余存储一份，依照店铺 ID 分片，(shop_id % 128)。不过因为商户数量较少，能够搞个异步线程往商户订单分片表同步。
订单依照用户 ID 分片后，产生数据歪斜怎么办？
因为不同用户的订单量是不同的，一个喜好购物的小姐姐的订单量抵得上几十个老爷们。导致一张表数据几百条，另一张表数据量千万级，这该咋整？
做冷热数据拆散，根底库只存储 3 个月内的订单，其余的挪动到历史订单库。这个要跟产品磋商好，3 个月前的订单须要独自的查问页面。
跨库事务问题：
这个问题就更简单了。
下一个订单须要调用多个服务，只能应用分布式事务。
分布式事务的实现非常复杂，罕用的有以下几种解决方案：
- 二阶段提交
- TCC
- 本地音讯表
- MQ 事务音讯
- 分布式事务中间件
面试官：筹备的挺全啊。订单表分片后，必定不能应用数据库自增主键做订单 ID，因为无奈全局惟一，有什么好的解决办法？
我：又问到我手心外面，我前两天刚看完一灯写的“雪花算法”，我现场手写订单 ID 的生成代码吧。
面试官：小伙子能够啊，下一面是 HR 面试，有薪资要求只管提，你肯定要来咱们公司下班。
总结：
对于分库分表的所有知识点，尽管很多，但都曾经总结在这张图上了。
文章继续更新，能够微信搜一搜「一灯架构」第一工夫浏览更多技术干货。