前几天有小伙伴在微信群里吐槽说，自己面试碰见面试官不问测试技术，一直关注代码和工具的底层实现，甚至问到了分库分表的实现原理，面试的结果呢当然是“今天的面试到此结束，如果合适的话后续会有通知”。 本着“有什么不开心的事说出来，让大家开心开心的原则”， 群里的小伙伴们纷纷出言献策，ＹＹ着要是自己面试会怎么回答。
随着互联网技术的演进，可以说，软件测试行业也进入了深水区，整个行业对ＱＡ的要求也越来越高，去ＱＥ的趋势特别明显，代码实现逻辑，设计模式这些以往问开发的问题也越来越常规的出现在ＱＡ的面试里，作为一名ＱＡ，靠”点点点“捣糨糊混江湖的日子一去不复返了，就我自己来说，面试中也越来越看重候选人对技术的深入是停留于表面还是锲而不舍的追宗溯源。
在日常的测试里，ＱＡ免不了跟数据库打交道，那么知道分库分表的原理并以此来设计你的测试用例，必然对你的测试结果有增效作用。
本着ＱＡ的自我修养精神，我总结了分库分表的知识点，供大家参考。
１. 为什么要分库分表？
因为服务器承受不住了啊。
随着业务的发展到一定程度，如果数据库没有采用分库分表，那么必然出现单位时间内的访问海量增加，导致的后果是同样的ＳＱＬ语句返回结果变慢，性能变差，出现甚至无响应的情况，接着ＣＰＵ或者ＩＯ出现瓶颈。如果不想线上出事故导致今年白干一年，分库分表就变成了必要操作。
需要注意的是，分库和分表是业务发展到一定阶段才会面临的问题。
分库和分表是两个操作，可以只分库不分表，也可以只分表不分库，还可以分库又分表。
２. 分库分表的方式？
目前业界的方式有两种：水平划分和垂直划分。
水平切分
把一个表的数据分散到多个表里去，达到的效果：
每个表的结构都一样；
每个表的数据都不一样，没有交集；
所有表的并集是全量数据；
水平切分的优点：
不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
应用端改造较小，不需要拆分业务模块
缺点：
跨分片的事务一致性难以保证
跨库的join关联查询性能较差
数据多次扩展难度和维护量极大
水平切分的具体实现方法：
1、根据数值范围
按照时间区间或ID区间来切分。
这样的优点在于：
单表大小可控
天然便于水平扩展，后期如果想对整个分片集群扩容时，只需要添加节点即可，无需对其他分片的数据进行迁移
使用分片字段进行范围查找时，连续分片可快速定位分片进行快速查询，有效避免跨分片查询的问题。
缺点：
- 热点数据成为性能瓶颈。
- 连续分片可能存在数据热点，例如按时间字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查询。
2、根据数值取模
一般采用hash取模mod的切分方式，例如：余数为0的放到第一个库，余数为1的放到第二个库，以此类推。这样同一个用户的数据会分散到同一个库中。
优点：
数据分片相对比较均匀，不容易出现热点和并发访问的瓶颈
缺点：
后期分片集群扩容时，需要迁移旧的数据（使用一致性hash算法能较好的避免这个问题）
容易面临跨分片查询的复杂问题。
比如上例中，如果频繁用到的查询条件中不带cusno时，将会导致无法定位数据库，从而需要同时向4个库发起查询，再在内存中合并数据，取最小集返回给应用，分库反而成为拖累。
垂直切分
垂直分库：基本的思路就是按照业务模块来划分出不同的数据库，而不是像早期一样将所有的数据表都放到同一个数据库中。
垂直分表：
“大表拆小表”，每个表的结构都不一样；
每个表的数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据；
所有表的并集是全量数据
垂直切分的优点：
解决业务系统层面的耦合，业务清晰
与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等
高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈
缺点：
部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度
分布式事务处理复杂
依然存在单表数据量过大的问题（需要水平切分）
３. 分库分表的工具？
cobar
TDDL
atlas
sharding-jdbc
mycat
参考资料：
《数据库架构：分库分表-垂直？水平？》，公号：搜云库技术团队。
《数据库分库分表思路》， 公号：后端技术精选。
其余有价值参考资料（直接搜）：
《数据库分库分表，何时分？怎样分？》，方志朋。
《分库分表的几种常见形式以及可能遇到的难题》，InfoQ。
