分库分表是在面对高并发、海量数量时常见的数据库层面的解决方案。通过把数据分散到不同的数据库中，使得单一数据库的数据量变小来缓解单一数据库的性能问题，从而达到提升数据库性能的目的。比如：将电商数据库拆分为若干独立的数据库，并且对于大表来说也拆分为若干小表，通过这种数据库拆分的方法来解决数据库的性能问题。
数据库分布式核心内容无非就是数据切分（Sharding），以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。
分库分表，顾名思义可以从两个角度来实现，一个是对数据库进行拆分，另一个是对表进行拆分。
二、分库分库主要是解决高并发的瓶颈问题，由于和数据库实例建立连接会消耗资源，所以不可能无限的分配连接资源，当对数据库的访问的QPS比较高时，就会对数据库实例造成很大的压力，并同时降低数据查询效率。MySQL中，可以使用max_connections查看默认的最大连接数，当访问连接数过多时，就会导致连接失败，此时将对一个数据库实例的操作拆分成对多个数据库实例的操作能有效降低这种压力。
那如何进行分库呢？在微服务架构中，通常会按照业务对数据库进行拆分，将业务关联度低的表划分到不同的数据库中，关联度高的表划分到相同的数据库中，这一般和微服务实践的服务拆分同时进行。
三、分表分表操作主要是为了解决数据量大的问题，但一张表中数据量过大，对该表的读写操作都会效率低下，这种情况可以对单表进行拆分操作。
通常意义上，单表行数超过万行或者单表容量超过2GB之后，才需要考虑做分库分表了。常见的拆分模式分为水平拆分和垂直拆分。
1.水平拆分水平拆分是将原始表按照一定的规则或策略分为多张子表，每张子表的字段数量没有变化，但是总记录数降低了，这样能够提高读写的效率。
优点：
不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
应用端改造较小，不需要拆分业务模块
缺点：
跨分片的事务一致性难以保证
跨库的join关联查询性能较差
数据多次扩展难度和维护量极大
一般水平拆分的策略包括：Hash取模拆分、按时间范围拆分、按空间范围拆分等。
2.垂直拆分垂直拆分是将原始表的字段拆分成几组，分别用不同的子表来保存，适合单表中字段已经非常多的情况，相较于水平拆分，垂直拆分的记录数量不会变，但单表的字段减少。在对字段进行垂直拆分的时候，需要区分哪些字段是热点字段？哪些字段是不常访问字段？对于热点字段可以单独拆分成一张表单独访问。
优点：
解决业务系统层面的耦合，业务清晰
与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等
高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈
提升读写的效率，并能够降低死锁的概率。
缺点：
部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度
分布式事务处理复杂
依然存在单表数据量过大的问题（需要水平切分）
在实际运用中，一般先考虑垂直拆分再考虑水平拆分，原因是水平拆分是将完整的记录被拆分到多表，需要解决多表关联查询等问题，而垂直拆分由于单表记录保存完整，只需要通过外键就能关联到子表，相对而言引入的问题更少。
Mysql本身也实现了分片存储的方案，将一张表分成N多个小表，分片是把一张表的数据分成N多个区块，这些区块可以在同一个磁盘上，也可以在不同的磁盘上。mysql的分表是真正的分表，一张表分成很多表后，每一个小表都是完整的一张表，都对应三个文件，一个.MYD数据文件，.MYI索引文件，.frm表结构文件。
四、常见问题1.数据倾斜通过Hash取模的方法解决数据倾斜的问题，对分片键进行Hash取模操作后再入库操作。
在使用Hash取模的方式对数据进行分片，当子表数量扩容后，所有老的数据再通过Hash取模可能都无法命中存储的子表，这种情况可以通过一致性Hash算法来解决。
一致性哈希可以按照常用的hash算法来将对应的key哈希到一个具有2^32次方个节点的空间中，形成成一个顺时针首尾相接的闭合的环形。所以当添加一台新的数据库服务器时，只有增加服务器的位置和逆时针方向第一台服务器之间的键会受影响。
2.跨节点多表关联查询切分之前，系统中很多列表和详情页所需的数据可以通过sqljoin来完成。而切分之后，数据可能分布在不同的节点上，此时join带来的问题就比较麻烦了，考虑到性能，尽量避免使用join查询。
全局关联表
常见的思路是在每个节点上都维护一个单独的全局关联表，保存需要查询的多表关联关系。
冗余字段
另一种思路是维护冗余字段，用来关联其他表的主键信息。这是一种用空间换时间的思路。
3.跨节点分组和排序对于跨节点的分组和排序操作，由于数据记录可能分散在不同的节点，一般是先读到内存中，再进行分组和排序操作。
4.分布式事务参考《分布式事务》一文
5.分布式ID参考《分布式ID》一文
五、总结优先考虑对表中索引和SQL进行优化，再考虑通过分库分表来进行优化，原因是分库分表对架构变更过大，并且对业务的侵入性过高，并且会引入很多的衍生问题。
一般的分库分表实践步骤：根据容量（当前容量和增长量）评估分库或分表个数-选key（均匀）-分表规则（hash或range等）-执行（一般双写）-扩容问题（尽量减少数据的移动）。
参考资料再有人问你什么是分库分表，直接把这篇文章发给他：