概述
分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分成若干数据库组成，将数据大表拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的。
分库分表方式：垂直分表、垂直分库、水平分库、水平分表。
分库分表带来问题：由于数据分散在多个数据库，服务器导致了事务一致性问题、跨节点join问题、跨节点分页、排序、函数，主键需要全局唯一，公共表。
最佳实践：
系统在设计之初就应该对业务数据的耦合松紧进行考量，从而进行垂直分库、垂直分表，使数据层架构清晰明了。若非必要，无需进行水平切分，应先从缓存技术着手降低对数据库的访问压力。如果缓存使用过后，数据库访问量还是非常大，可以考虑数据库读、写分离原则。若当前数据库压力依然大，且业务数据持续增长无法估量，最后可考虑水平分库、分表，单表拆分数据控制在1000万以内。
垂直分表
将一个表按照字段分成多表，每个表存储其中一部分字段。
当表数据量很大时，可以将表按字段切开，将热门字段、冷门字段分开放置在不同库中，这些库可以放在不同的存储设备上，避免IO争抢。垂直切分带来的性能提升主要集中在热门数据的操作效率上，而且磁盘争用情况减少。
通常我们按以下原则进行垂直拆分:
- 把不常用的字段单独放在一张表;
- 把text，blob等大字段拆分出来放在附表中;
- 经常组合查询的列放在一张表中;
垂直分库
指按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上，它的核心理念
是专库专用。
带来的好处：
- 解决业务层面的耦合，业务清晰
- 能对不同业务的数据进行分级管理、维护、监控、扩展等
- 高并发场景下，垂直分库一定程度的提升 IO、数据库连接数、降低单机硬件资源的瓶颈
垂直分库通过将表按业务分类，然后分布在不同数据库，并且可以将这些数据库部署在不同服务器上，从而达到多个服务器共同分摊压力的效果，但是依然没有解决单表数据量过大的问题。
水平分库
同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上。
带来的好处：
- 解决了单库大数据，高并发的性能瓶颈。
- 提高了系统的稳定性及可用性。
水平分表
在同一个数据库内，把同一个表的数据按一定规则拆到多个表中。
带来的好处：
- 优化单一表数据量过大而产生的性能问题
- 避免 IO争抢并减少锁表的几率
库内的水平分表，解决了单一表数据量过大的问题，分出来的小表中只包含一部分数据，从而使得单个表的数据量变小，提高检索性能。
分表的根本原因
分表的原动力在于 MySQL 单表性能问题。
据说 MySQL 单表数据量超过 N 千万、或者表 Size 大于 N十G 性能就不行了。这个说法背后的逻辑是数据量超过一定大小，B+Tree 索引的高度就会增加，而每增加一层高度，整个索引扫描就会多一次 IO 。整个逻辑有一定道理，而从笔者的经验来看，其实更关键在于应用本身的使用，如果多数是索引命中率很高的点查或者小范围查，其实这个上限还很高，我们维护的系统里超过10亿级的表很常见。但正是由于业务的不可控，所以大家往往采取比较保守的策略，这就是分表的原因。
分库+分表的根本原因
MySQL 并发写入量过大，从而导致的主从同步数据延迟问题。
分库主要由于 MySQL 容量上，MySQL 的写入是很昂贵的操作，它本身有很多优化技术，即使如此，写入也存在放大很多倍的现象。同时 MySQL M-S 的架构虽然天然地支持读流量扩展，但由于 MySQL 从库复制默认采用单线程的 SQL thread 进行 Binlog 顺序重放，这种单线程的从库写入极大地限制整个集群的写入能力，（除非不在意数据延迟，而数据延迟与否直接影响了读流量的可用性）。MySQL 基于组提交的并行复制从某种程度上缓解了这个问题，但本质上写入上限还是非常容易达到（实际业务也就 小几千 的 TPS ) 。说到这，目前有一些云 RDS 通过计算与存储分离、log is database 的理念来很大程度解决了写入扩大的问题，但在这之前，更为普遍的解决方案就是把一个集群拆分成 N 个集群，即分库分表（sharding）。为了规避热点问题，绝大多数采用的方法就是 hash 切分，也有极少的范围、或者基于 Mapping 的查询切分。
DB proxy 和 JDBC proxy
DB proxy
在应用层与数据源之间增加了一层代理层。相关中间件：MyCat，Atlas，Cobar等
优点：①server端中间件负责集群管理，集群中节点的变化不需要通知到每个客户端；②部署和升级相对方便；③元数据集中管理，分片策略可以灵活定制；④方便实现全局唯一ID和事务管理。
缺点：①中间件是单点，需要通过其它方式做高可用；②链路过长，每层都会增加响应时间。
JDBC proxy
在应用层中，引入sharding-jdbc的jar包，对jdbc进行增强。最大的问题是违背了 DB 透明的原则，它需要对不同的语言编写。
优点：①每台应用的客户端地位相同，提供了高可用性；②对性能损耗小。
缺点：①全局主键分配，集群变化，事务管理等需要节点间通信；②DB 不透明。
评论区