页面（只有商品基本信息，没有商品详情信息）：
数据库：
通过以下SQL能够获取到商品相关的店铺信息、地理区域信息：
1 SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉] 2 FROM [商品信息] p 3 LEFT JOIN [地理区域] r ON p.[产地] = r.[地理区域编码] 4 LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺] 5 WHERE p.id = ?
| 垂直分表 | 以字段为维度，根据冷热数据拆分（如：商品基本信息字段和商品详细信息字段） |
| 垂直分库 | |
| 水平分库 |
以业务为维度，根据不同业务拆分，专库专用（如：商品库，店铺库） 水平分表较水平分库可减少数据库实例，降低运维的成本 |
| 水平分表 |
将访问频次低的商品描述信息单独存放在一张表中，访问频次较高的商品基本信息单独放在一张表中。
用户在浏览商品列表时，只有对某商品感兴趣时才会查看该商品的详细描述。因此，商品信息中商品描述字段访问频次较低，且该字段存储占用空间较大，访问单个数据IO时间较长；商品信息中商品名称、商品图片、商品价格等其他字段数据访问频次较高。
由于这两种数据的特性不一样，因此他考虑将商品信息表拆分如下：
将访问频次低的商品描述信息单独存放在一张表中，访问频次较高的商品基本信息单独放在一张表中。
商品列表可采用以下sql：
1 SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉] 2 FROM [商品信息] p 3 LEFT JOIN [地理区域] r ON p.[产地] = r.[地理区域编码] 4 LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺] 5 WHERE...ORDER BY...LIMIT...
需要获取商品描述时，再通过以下sql获取：
1 SELECT * 2 FROM [商品描述] 3 WHERE [商品ID] = ?
垂直分表定义：将一个表按照字段分成多表，每个表存储其中一部分字段。
它带来的提升是：
1.为了避免IO争抢并减少锁表的几率，查看详情的用户与商品信息浏览互不影响
2.充分发挥热门数据的操作效率，商品信息的操作的高效率不会被商品描述的低效率所拖累。
为什么大字段IO效率低：第一是由于数据量本身大，需要更长的读取时间；第二是跨页，页是数据库存储单位，很多查找及定位操作都是以页为单位，单页内的数据行越多数据库整体性能越好，而大字段占用空间大，单页内存储行数少，因此IO效率较低。第三，数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了磁盘IO，从而提升了数据库性能。
一般来说，某业务实体中的各个数据项的访问频次是不一样的，部分数据项可能是占用存储空间比较大的BLOB或是TEXT。例如上例中的商品描述。所以，当表数据量很大时，可以将表按字段切开，将热门字段、冷门字段分开放置在不同库中，这些库可以放在不同的存储设备上，避免IO争抢。垂直切分带来的性能提升主要集中在热门数据的操作效率上，而且磁盘争用情况减少。
通常我们按以下原则进行垂直拆分:
通过垂直分表性能得到了一定程度的提升，但是还没有达到要求，并且磁盘空间也快不够了，因为数据还是始终限制在一台服务器，库内垂直分表只解决了单一表数据量过大的问题，但没有将表分布到不同的服务器上，因此每个表还是竞争同一个物理机的CPU、内存、网络IO、磁盘。
经过思考，他把原有的SELLER_DB(卖家库)，分为了PRODUCT_DB(商品库)和STORE_DB(店铺库)，并把这两个库分散到不同服务器，如下图：
由于商品信息与商品描述业务耦合度较高，因此一起被存放在PRODUCT_DB(商品库)；而店铺信息相对独立，因此单独被存放在STORE_DB(店铺库)。
垂直分库是指按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上，它的核心理念是专库专用。
它带来的提升是：
解决业务层面的耦合，业务清晰
能对不同业务的数据进行分级管理、维护、监控、扩展等
高并发场景下，垂直分库一定程度的提升IO、数据库连接数、降低单机硬件资源的瓶颈
垂直分库通过将表按业务分类，然后分布在不同数据库，并且可以将这些数据库部署在不同服务器上，从而达到多个服务器共同分摊压力的效果，但是依然没有解决单表数据量过大的问题。
经过垂直分库后，数据库性能问题得到一定程度的解决，但是随着业务量的增长，PRODUCT_DB(商品库)单库存储数据已经超出预估。粗略估计，目前有8w店铺，每个店铺平均150个不同规格的商品，再算上增长，那商品数量得往1500w+上预估，并且PRODUCT_DB(商品库)属于访问非常频繁的资源，单台服务器已经无法支撑。此时该如何优化？
再次分库？但是从业务角度分析，目前情况已经无法再次垂直分库。
尝试水平分库，将店铺ID为单数的和店铺ID为双数的商品信息分别放在两个库中。
也就是说，要操作某条数据，先分析这条数据所属的店铺ID。如果店铺ID为双数，将此操作映射至RRODUCT_DB1(商品库1)；如果店铺ID为单数，将操作映射至RRODUCT_DB2(商品库2)。此操作要访问数据库名称的表达式为RRODUCT_DB[店铺ID%2 + 1] 。
水平分库是把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上。
垂直分库是把不同表拆到不同数据库中，它是对数据行的拆分，不影响表结构
它带来的提升是：
稳定性体现在IO冲突减少，锁定减少，可用性指某个库出问题，部分可用`
当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平分库了，经过水平切分的优化，往往能解决单库存储量及性能瓶颈。但由于同一个表被分配在不同的数据库，需要额外进行数据操作的路由工作，因此大大提升了系统复杂度。
按照水平分库的思路对他把PRODUCT_DB_X(商品库)内的表也可以进行水平拆分，其目的也是为解决单表数据量大的问题，如下图：
与水平分库的思路类似，不过这次操作的目标是表，商品信息及商品描述被分成了两套表。如果商品ID为双数，将此操作映射至商品信息1表；如果商品ID为单数，将操作映射至商品信息2表。此操作要访问表名称的表达式为商品信息[商品ID%2 + 1] 。
水平分表是在同一个数据库内，把同一个表的数据按一定规则拆到多个表中。
它带来的提升是：
优化单一表数据量过大而产生的性能问题
避免IO争抢并减少锁表的几率
库内的水平分表，解决了单一表数据量过大的问题，分出来的小表中只包含一部分数据，从而使得单个表的数据量变小，提高检索性能。
垂直分表：可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表，这样既能使业务清晰，还能提升部分性能。拆分后，尽量从业务角度避免联查，否则性能方面将得不偿失。
垂直分库：可以把多个表按业务耦合松紧归类，分别存放在不同的库，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能，同时能提高整体架构的业务清晰度，不同的业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题。
水平分库：可以把一个表的数据(按数据行)分到多个不同的库，每个库只有这个表的部分数据，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能。它不仅需要解决跨库带来的所有复杂问题，还要解决数据路由的问题(数据路由问题后边介绍)。
水平分表：可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中，每个表只有这个表的部分数据，这样做能小幅提升性能，它仅仅作为水平分库的一个补充优化。
一般来说，在系统设计阶段就应该根据业务耦合松紧来确定垂直分库，垂直分表方案，在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案。若数据量极大，且持续增长，再考虑水平分库水平分表方案。
转：https://blog.csdn.net/weixin_44062339/article/details/100491744
1、分布式事务问题：？下面要提的ShardingJDBC无法解决
2、跨节点关联查询问题：连接查询
3、跨节点分页、排序问题：合并多个查询结果之后再分页或者排序
4、主键避重问题：全局主键
5、公共表问题（如城市表）：每个库都有一个公共表，分别去操作
Sharding-JDBC主要是操作分库和分的表。核心功能是数据分页和读写分离。透明的使用JDBC访问已经分库分表、读写分离的多个数据源，而不用关心数据源的数量以及其数据如何分布。
架构图：
分片规则配置：
1、数据源
2、配置数据节点（库,表）
3、主键生成策略（全局主键-SNOWFLAKE雪花算法）
4、分片策略（分片键+分片算法）
sharding.jdbc.datasource.names=test0,test1
sharding.jdbc.datasource.test0.type=org.apache.commons.dbcp2.BasicDataSource
sharding.jdbc.datasource.test0.driver-class-name=com.mysql.jdbc.Driver
sharding.jdbc.datasource.test0.url=jdbc:mysql://localhost:3306/test0
sharding.jdbc.datasource.test0.username=root
sharding.jdbc.datasource.test0.password=123456
sharding.jdbc.datasource.test1.type=org.apache.commons.dbcp2.BasicDataSource
sharding.jdbc.datasource.test1.driver-class-name=com.mysql.jdbc.Driver
sharding.jdbc.datasource.test1.url=jdbc:mysql://localhost:3306/test1
sharding.jdbc.datasource.test1.username=root
sharding.jdbc.datasource.test1.password=123456
sharding.jdbc.config.sharding.default-database-strategy.inline.sharding-column=user_id
sharding.jdbc.config.sharding.default-database-strategy.inline.algorithm-expression=ds$->{user_id % 2}
sharding.jdbc.config.sharding.tables.t_order.actual-data-nodes=test$->{0..1}.t_order$->{0..1} <!--Groovy表达式,代表$的取值为0到1-->
sharding.jdbc.config.sharding.tables.t_order.table-strategy.inline.sharding-column=order_id
sharding.jdbc.config.sharding.tables.t_order.table-strategy.inline.algorithm-expression=t_order$->{order_id % 2}
sharding.jdbc.config.sharding.tables.t_order.key-generator.column=order_id
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sharding="http://shardingsphere.apache.org/schema/shardingsphere/sharding" xmlns:bean="http://www.springframework.org/schema/util" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://shardingsphere.apache.org/schema/shardingsphere/sharding http://shardingsphere.apache.org/schema/shardingsphere/sharding/sharding.xsd http://www.springframework.org/schema/util https://www.springframework.org/schema/util/spring-util.xsd" default-lazy-init="false"> <!-- 配置多数据源 --> <bean id="db_test_0" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" destroy-method="close" primary="false"> <property name="driverClassName" value="com.mysql.jdbc.Driver" /> <property name="url" value="jdbc:mysql://${jdbc.sharding.addr}/db_test_0?useSSL=false&useUnicode=true&characterEncoding=UTF-8&allowMultiQueries=true&zeroDateTimeBehavior=convertToNull" /> <property name="username" value="${jdbc.sharding.username}" /> <property name="password" value="${jdbc.sharding.password}" /> <property name="initialSize" value="${druid.initialSize}"/> <property name="maxActive" value="${druid.maxActive}"/> <property name="maxWait" value="${druid.maxWait}"/> <property name="validationQuery" value="SELECT ‘x‘" /> <property name="testWhileIdle" value="true" /> <property name="timeBetweenEvictionRunsMillis" value="60000 " /> <property name="testOnBorrow" value="false" /> <property name="testOnReturn" value="false" /> </bean> <bean id="db_test_1" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" destroy-method="close" primary="false"> <property name="driverClassName" value="com.mysql.jdbc.Driver" /> <property name="url" value="jdbc:mysql://${jdbc.sharding.addr}/db_test_1?useSSL=false&useUnicode=true&characterEncoding=UTF-8&allowMultiQueries=true&zeroDateTimeBehavior=convertToNull" /> <property name="username" value="${jdbc.sharding.username}" /> <property name="password" value="${jdbc.sharding.password}" /> <property name="initialSize" value="${druid.initialSize}"/> <property name="maxActive" value="${druid.maxActive}"/> <property name="maxWait" value="${druid.maxWait}"/> <property name="validationQuery" value="SELECT ‘x‘" /> <property name="testWhileIdle" value="true" /> <property name="timeBetweenEvictionRunsMillis" value="60000 " /> <property name="testOnBorrow" value="false" /> <property name="testOnReturn" value="false" /> </bean> <bean id="db_test_2" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" destroy-method="close" primary="false"> <property name="driverClassName" value="com.mysql.jdbc.Driver" /> <property name="url" value="jdbc:mysql://${jdbc.sharding.addr}/db_test_2?useSSL=false&useUnicode=true&characterEncoding=UTF-8&allowMultiQueries=true&zeroDateTimeBehavior=convertToNull" /> <property name="username" value="${jdbc.sharding.username}" /> <property name="password" value="${jdbc.sharding.password}" /> <property name="initialSize" value="${druid.initialSize}"/> <property name="maxActive" value="${druid.maxActive}"/> <property name="maxWait" value="${druid.maxWait}"/> <property name="validationQuery" value="SELECT ‘x‘" /> <property name="testWhileIdle" value="true" /> <property name="timeBetweenEvictionRunsMillis" value="60000 " /> <property name="testOnBorrow" value="false" /> <property name="testOnReturn" value="false" /> </bean> <!-- 配置分库分表策略，库表各有一个分片策略文件 --> <bean id="dataSourceStrategy" class="com.fangyan.test.dal.strategy.DataSourceStrategy"/> <bean id="dataTableStrategy" class="com.fangyan.test.dal.strategy.DataTableStrategy"/> <sharding:standard-strategy id="databaseStrategy" sharding-column="f_user_id" precise-algorithm-ref="dataSourceStrategy"/> <sharding:standard-strategy id="orderTableStrategy" sharding-column="f_user_id" precise-algorithm-ref="dataTableStrategy"/> <!-- sharding数据源,分三个库，每个库中又分15个表 --> <sharding:data-source id="shardingDataSource"> <sharding:sharding-rule data-source-names="db_test_0,db_test_1,db_test_2"> <sharding:table-rules> <sharding:table-rule logic-table="t_order_info" key-generator-ref="keyGenerator" actual-data-nodes="db_test_$->{0..2}.t_order_$->{0..15}" database-strategy-ref="databaseStrategy" table-strategy-ref="orderTableStrategy" /> </sharding:table-rules> </sharding:sharding-rule> <sharding:props> <prop key="sql.show">false</prop> </sharding:props> </sharding:data-source> <!-- 雪花算法ID生成器,自定义的主键生成器 --> <sharding:key-generator id="keyGenerator" column="order_id" type="SIMPLE" /> </beans>
spring:
shardingsphere:
datasource: ## 略......
sharding:
tables:
t_order:
## 指定 t_order表的 数据分布情况，配置数据节点
actual-data-nodes: m1.t_order_$->{1..2}
## 指定t_order表的主键列，以及主键生成策略为SNOWFLAKE
key-generator:
column: order_id
## 指定分片策略类型
type: SIMPLE
## 指定t_order的分片策略： 设置分片键和分片算法
table-strategy:
inline:
sharding-column: order_id
## 根据order_id % 2 + 1 的结果，指定t_order的实际表
algorithm-expression: t_order_$->{order_id % 2 +1}
sharding-jdbc提供了两种主键生成策略UUID、SNOWFLAKE ,默认使用SNOWFLAKE,还抽离出分布式主键生成器的接口org.apache.shardingsphere.spi.keygen.ShardingKeyGenerator，方便用户自行实现自定义的自增主键生成器。
public class SimpleShardingKeyGenerator implements ShardingKeyGenerator { private AtomicLong atomic = new AtomicLong(0); @Getter @Setter private Properties properties = new Properties(); @Override public Comparable<?> generateKey() { return atomic.incrementAndGet(); } @Override public String getType() { //声明类型 return "SIMPLE"; } }
新增：新增的时候，主键不用赋值了，由雪花算法自动生成
查询：当查询的数据涉及多个库表，真实的查询sql会在多个库表中查询，执行了多次查询。
执行流程分析：
1、解析SQL，获取分片键对应的字段的值
2、通过分片策略计算分片值确定库表（逻辑表解析成真实表，并且解析到对应的数据源和表上。）
3、根据分片值改写SQL，改写后的SQL是要执行的真实SQL
4、执行改写后的真实SQL
5、将SQL的执行结果合并返回
结果归并：遍历、排序、分组、分页、聚合
1、内存归并：所有结果集在内存中进行合并
2、流水式归并：一边处理，一边归并
3、装饰者归并：对归并结果集增强
基本概念：
绑定表：分片键相同的两个表互为绑定表关系（如：商品基本信息表及详细信息表）。绑定表查询不会笛卡尔积，查询效率高。
广播表：公共表
广播路由：没有分片键，所有的库表都执行SQL
未完待续》》》》》》》》》》》》》》》》》》》》》》》
原文：https://www.cnblogs.com/fangyanr/p/13986319.html