1 、基本概念
1. 什么是ShardingSphere?
定义
Apache ShardingSphere 是一款开源的分布式数据库生态项目，由 JDBC 和 Proxy 这两款产品组成。
其核心采用可插拔架构，通过组件扩展功能。 对上以数据库协议及 SQL 方式提供诸多增强功能，包括数据分片、访问路由、数据安全等；对下原生支持
MySQL、PostgreSQL、SQL Server、Oracle 等多种数据存储引擎。 Apache ShardingSphere
项目理念，是提供数据库增强计算服务平台，进而围绕其上构建生态。
充分利用现有数据库的计算与存储能力，通过插件化方式增强其核心能力，为企业解决在数字化转型中面临的诸多使用难点，为加速数字化应用赋能
ShardingSphere 已于 2020 年 4 月 16 日成为 Apache 软件基金会的顶级项目。 欢迎通过邮件列表参与讨论。
ShardingSphere-JDBC
ShardingSphere-JDBC 是 Apache ShardingSphere 的第一个产品，也是 Apache ShardingSphere 的前身。定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。
适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC；
支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, HikariCP 等；
支持任意实现 JDBC 规范的数据库，目前支持 MySQL，PostgreSQL，Oracle，SQLServer 以及任何可使用 JDBC 访问的数据库。
ShardingSphere-JDBC |
ShardingSphere-Proxy | |
| 数据库 | 任意 | MySQL/PostgreSQL |
| 连接消耗数 | 高 | 低 |
| 异构语言 | 仅 Java | 任意 |
| 性能 | 损耗低 | 损耗略高 |
| 无中心化 | 是 | 否 |
| 静态入口 | 无 | 有 |
ShardingSphere-JDBC的优势在于对 Java 应用的友好度。
ShardingSphere-Proxy
ShardingSphere-Proxy 是 Apache ShardingSphere 的第二个产品。它定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前提供 MySQL 和 PostgreSQL（兼容 openGauss 等基于 PostgreSQL 的数据库）版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端（如：MySQL Command Client, MySQL Workbench, Navicat 等）操作数据，对 DBA 更加友好。
向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用；
适用于任何兼容 MySQL/PostgreSQL 协议的的客户端。
ShardingSphere-JDBC |
ShardingSphere-Proxy | |
| 数据库 | 任意 | MySQL/PostgreSQL |
| 连接消耗数 | 高 | 低 |
| 异构语言 | 仅 Java | 任意 |
| 性能 | 损耗低 | 损耗略高 |
| 无中心化 | 是 | 否 |
| 静态入口 | 无 | 有 |
产品定位
构建异构数据库上层生态和标准
Apache ShardingSphere 产品定位为 Database Plus，旨在构建异构数据库上层的标准和生态。 它关注如何充分合理地利用数据库的计算和存储能力，而并非实现一个全新的数据库。 ShardingSphere 站在数据库的上层视角，关注他们之间的协作多于数据库自身。
在原有关系型数据库基础上提供扩展和增强
Apache ShardingSphere 旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力， 并非实现一个全新的关系型数据库。 关系型数据库当今依然占有巨大市场份额，是企业核心系统的基石，未来也难于撼动，我们更加注重在原有基础上提供增量，而非颠覆。
统一管控的多端接入
Apache ShardingSphere 是多接入端共同组成的生态圈。 通过混合使用 ShardingSphere-JDBC 和 ShardingSphere-Proxy，并采用同一注册中心统一配置分片策略，能够灵活的搭建适用于各种场景的应用系统，使得架构师更加自由地调整适合于当前业务的最佳系统架构。
老版本官网内容：
1 、一套开源的分布式数据库中间件解决方案
2 、有三个产品：Sharding-JDBC和Sharding-Proxy（第3给本章不扩展暂不写）
3 、定位为关系型数据库中间件，合理在分布式环境下使用关系型数据库操作
2.什么是分库分表
（把一个大的数据库DB,可以先拆分为商品库和商家库，然后在进行表的拆分，商品DB拆分分商品表1，2；商家DB同理拆分2个表）
1 、数据库数据量不可控的，随着时间和业务发展，造成表里面数据越来越多，如果再去对数
据库表curd操作时候，造成性能问题。
2 、方案 1 ：从硬件上（对于资金耗费较大）
3 、方案 2 ：分库分表
为了解决由于数据量过大而造成数据库性能降低问题。
分库分表的方式
1 、分库分表有两种方式：垂直切分和水平切分
2 、垂直切分：垂直分表和垂直分库
3 、水平切分：水平分表和水平分库
4 、垂直分表
（ 1 ）操作数据库中某张表，把这张表中一部分字段数据存到一张新表里面，再把这张表另一 部分字段数据存到另外一张表里面
总而言之：就是把一个表中的多个字段拆分一下，根据你的表的内容可以拆分几个或者多个表，去对应每个表中的不同的数据；当你再修改课程的时候他的同一个字段的课程价格其实是不受影响的也就是不会上锁不影响到其他用户进行查询；
5 、垂直分库
（ 1 ）把单一数据库按照业务进行划分，专库专表
怎么说下呢？ 针对业务场景不同在 业务场景中存放在不同的数据库当中 也就是有多个库，库中有多个表；例如上面的 课程库中 放课程相关数据表；相关的业务场景都会去课程库中进行查询；
6 、水平分库
水平分库：其实就是把一个数据库分成多个 结构类型一模一样的多个数据库；里面除了数据不一样其他都一样；存的时候可以根据ID%2得出偶数奇数的id 去针对他们id 存在不同的数据库当中；
7 、水平分表
同一个数据库当中，库不变，在库中创建多个一模一样的表，就像上图；我们可以把课程信息，课程描述表进行再次新增一个表；也可以根据id去存不同的数据当相同的表；也为了减少数据量比较大的情况；
垂直 库和表是不同的；水平 则是相同的；
分库分表应用和问题(总结)
1 、应用
（ 1 ）在数据库设计时候考虑垂直分库和垂直分表
（ 2 ）随着数据库数据量增加，不要马上考虑做水平切分，首先考虑缓存处理，读写分离，使用索引等等方式，如果这些方式不能根本解决问题了，再考虑做水平分库和水平分表
2 、分库分表问题
（ 1 ）跨节点连接查询问题（分页、排序）
查询表（库）中数据的时候需要进行多表关联多次查询才能得出结果；
（ 2 ）多数据源管理问题
在服务器中可能多遇到跨节点连接查询，多数据源连接问题；
