1. 什么是分库分表
1.1 数据库瓶颈
1.1.1 IO瓶颈
- 磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表
- 网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库
1.1.2 CPU瓶颈
- SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算
- 单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表
1.2 分库分表
分库分表有两种方式：垂直切分和水平切分。其中垂直切分包含垂直分表和垂直分库；水平切分包含水平分表和水平分库。
1.2.1 水平分库
1.2.2 水平分表
1.2.3 垂直分库
1.2.4 垂直分表
1.3 分库分表的应用和问题
随着数据库数据量的增加，开发者不应该马上考虑做水平切分，应该首先考虑使用缓存、读写分离、索引优化等手段（原因在于分库分表后会引入一些问题，如：跨节点连接查询[join]、排序[order by]、计数[count]、分组[group by]、分页等操作的复杂度提高；以及多数据源的管理问题），如果这些方式不能根本性解决问题，再考虑分库分表。同时在数据库设计的时候就要考虑到垂直分库和垂直分表。
2. Apache ShardingSphere是什么
关于ShardingSphere ，可以参考其官网介绍：
2.1 ShardingSphere-JDBC
定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。
- 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC。
- 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等。
- 支持任意实现 JDBC 规范的数据库，目前支持 MySQL，Oracle，SQLServer，PostgreSQL 以及任何遵循 SQL92 标准的数据库。
2.2 ShardingSphere-Proxy
定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前提供 MySQL 和 PostgreSQL 版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端(如：MySQL Command Client, MySQL Workbench, Navicat 等)操作数据，对 DBA 更加友好。
- 向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用。
- 适用于任何兼容 MySQL/PostgreSQL 协议的的客户端。
2.3 ShardingSphere-Sidecar(TODO)
该模块目前还在开发中，这里不予探究。
2.4 混合架构
上面是三者之间的对比，结合之前的介绍，不难看出，ShardingSphere-JDBC 采用无中心化架构，适用于 Java 开发的高性能的轻量级 OLTP 应用；ShardingSphere-Proxy 提供静态入口以及异构语言的支持，适用于 OLAP 应用以及对分片数据库进行管理和运维的场景。
Apache ShardingSphere 是多接入端共同组成的生态圈。 通过混合使用 ShardingSphere-JDBC 和 ShardingSphere-Proxy，并采用同一注册中心统一配置分片策略，能够灵活的搭建适用于各种场景的应用系统，使得架构师更加自由地调整适合与当前业务的最佳系统架构。
