Sharding sphere分库分表

需要物理自己实现分表分库，然后通过配置文件配置。

配置文件：

需要配置多个数据源，主从表的关系【默认主表修改，从表读取】，定义分库的策略【比如User id】和分表【表Id】的策略

分库和分表策略：分库策略定义了如何将数据分配到不同的数据库中，例如，可以根据用户ID的范围来进行分库。分表策略定义了如何将数据在表级别进行分片，例如，可以根据表ID来进行分表。

过程：

从解析sql到路由sql再到改写sql最后到sql执行然后将数据归并回来，改写过程中可能会增加列，因为路由的时候需要聚合或者分组需要带上某些id。

解析SQL：当 ShardingSphere 接收到一个 SQL 语句时，它首先解析该语句以理解其结构和内容。
路由SQL：根据解析后的信息和分库分表策略，ShardingSphere 决定这个 SQL 语句应该发送到哪个数据库实例和具体的表上执行。
改写SQL：在路由决定后，ShardingSphere 可能需要修改原始的 SQL 语句以适应目标数据库实例和表，比如修改表名为实际的分片表名。
SQL执行：改写后的 SQL 语句被发送到目标数据库实例执行。
归并数据：如果一个查询操作涉及到多个数据库实例或表，ShardingSphere 会收集所有返回的数据，然后将它们归并在一起返回给用户。归并过程中可能会涉及到排序、分组、聚合等操作。

改写过程中可能会增加列：在 SQL 改写的过程中，可能需要增加额外的信息，比如分片键列，以确保数据的一致性和正确的归并操作。

总体来讲，ShardingSphere 通过这个过程，对外提供了一个透明的数据库分库分表操作，对应用层来说，它就像访问单一数据库一样。这个架构能够在不更改应用程序代码的情况下，对数据库进行水平扩展，提升了系统的可扩展性和可用性。

举个例子

假设我们有一个 User 表，它非常大，包含数百万用户数据。为了提高查询性能和数据的可管理性，我们决定将这个 User 表进行分库分表。

分库策略：

我们可以根据用户的地理位置（例如用户的国家码）来进行分库。假设我们有三个数据库实例，Database A、Database B 和 Database C，我们可以这样分配：

Database A 存储国家码为1的用户数据
Database B 存储国家码为2的用户数据
Database C 存储国家码为3的用户数据

这种策略可以通过配置 ShardingSphere 来实现。当一个请求进来时，ShardingSphere 查看用户的国家码，然后决定将请求路由到哪个数据库实例。

分表策略：

对于每个数据库实例中的 User 表，我们还可以根据用户的 ID 进行分表。假设我们决定每张表存储10000条用户记录，我们可以有如下的分表：

User_0001 存储 ID 1 到 10000 的用户数据
User_0002 存储 ID 10001 到 20000 的用户数据
User_0003 存储 ID 20001 到 30000 的用户数据
依此类推...

这样，当我们有一个查询请求来查找 ID 为 15000 的用户时，ShardingSphere 首先通过分库策略确定这个用户在哪个数据库实例，然后通过分表策略确定这个用户在哪张表中。如果 ID 15000 的用户属于国家码为2的范围，则 ShardingSphere 将查询路由到 Database B 的 User_0002 表中。

配置分库分表策略的关键是确定分片键（Sharding Key），它是用于分片的字段。在我们的例子中，国家码可以是分库的分片键，用户 ID 可以是分表的分片键。

通过以上方式，ShardingSphere 能够管理大规模分布式数据库系统，提升性能，降低单个数据库的压力。这是实现大规模数据库水平扩展的常用方法。

执行

执行有2种模式：内存限制【做分析的数据库，连接量不高，聚合运算和数据量比较多】和连接限制【事务型数据库连接限制比较大】，

在数据库管理和优化中，根据不同的使用场景，数据库系统可能会被配置为不同的执行模式，特别是在处理资源分配和性能优化时。这里描述的“内存限制”和“连接限制”模式反映了两种不同的资源管理策略：

内存限制模式：在内存限制模式下，数据库系统的主要瓶颈是内存资源。这种模式适用于那些需要进行大量数据处理和复杂查询的数据库，如数据仓库、分析型数据库或报表系统。这些系统往往执行大规模的聚合和分析运算，需要缓存大量数据来计算结果。由于查询的复杂性和数据量的大小，数据库的内存使用变得非常关键。

在内存限制模式下，数据库管理员可能需要精细地配置内存管理参数，例如缓存大小、查询执行内存限制等，以防止查询操作消耗过多的内存而影响到整个数据库系统的稳定性。
连接限制模式：在连接限制模式下，数据库系统的主要瓶颈是并发连接数量，也就是同时连接到数据库的客户端数量。这种模式适用于那些以事务处理为主的数据库，如在线事务处理系统（OLTP），这类系统通常处理大量的短期交易。

事务型数据库通常需要优化连接池，及时释放不活跃连接，并确保数据库能够高效地处理大量并发事务。在这种模式下，数据库管理员可能需要配置诸如最大连接数、连接超时时间、事务隔离级别等参数，以提高并发处理能力并保证数据的一致性。

在实际的生产环境中，选择合适的模式是根据应用的特性和需求来决定的。对数据库系统进行适当的配置和调优可以帮助达到最佳的性能表现和资源利用率。例如，对于一个分析型数据库，可能会分配较多的内存给数据处理和聚合计算；而对于一个高并发的Web应用，可能需要优化数据库的连接池和事务处理能力。

以下是在使用 ShardingSphere 时可以考虑的一些通用配置方向：

针对内存限制：
- 如果你的应用主要进行复杂查询和大量的数据聚合，你可能需要为每个数据库实例配置足够的内存，以支持这些操作。这可能包括调整数据库缓存大小、工作内存（比如 PostgreSQL 的 work_mem）和其他相关内存参数。
- 在 ShardingSphere 配置中，你可能需要关注 SQL 执行的优化，确保复杂查询能够有效分发到合适的分片上执行。
针对连接限制：
- 对于需要处理高并发事务的应用，确保数据库连接池参数（如最大连接数、最小空闲连接数、连接超时时间等）得到适当配置非常关键。
- ShardingSphere 可以配置读写分离规则，将读操作路由到从库从而减轻主库的压力。
- 考虑使用数据库连接池（如 HikariCP、DBCP、C3P0 等）来管理数据库连接。
分片策略配置：
- 对于分库分表策略，合理地定制分片算法和分片键可以帮助平衡跨多个数据库实例和表的数据分布和查询负载。
监控和调试：
- 启用监控功能来跟踪数据库的性能和资源利用情况，这样你可以在出现性能瓶颈时快速定位问题并进行优化。

在配置 ShardingSphere 或任何数据库中间件时，重要的是要充分理解你的业务需求和数据库的负载特征，以便做出恰当的决策。建议在进行任何重大更改之前对配置进行测试，以确保它们能够达到预期的效果，并且不会对现有的系统产生负面影响。

最佳配置很大程度上取决于具体的应用场景，包括数据模式、访问模式、硬件资源和性能目标。因此，最好的做法是进行基准测试和监控来逐步调整和优化设置。

逻辑表：没有后缀的表，前缀一致的表，分表前的名字

真实表：分表后的完整名

绑定表：用同样的分片逻辑能保持一致，不会出现太多笛卡尔积的结果

广播表：每个库都有的表，就是字典表

建议：自研，适合自己的业务才是最合适的。

在使用分库分表框架，如 Apache ShardingSphere 进行数据库设计时，你会遇到几个专有名词：逻辑表、真实表、绑定表和广播表。以下是它们的含义：

逻辑表 (Logical Table): 逻辑表是指用户在编写 SQL 时使用的表名。这个名称并不对应数据库中的实际物理表，而是一个虚拟的概念，代表了可能分散在多个真实表或分片表中的数据集合。在分库分表策略中，逻辑表通常由多个真实表组成，它们共同承载了逻辑表数据。

例如，你有一个逻辑表 user，它由 user_0, user_1, user_2 等真实表组成。
真实表 (Actual Table): 真实表或物理表是指数据库中实际存在的表。这些表是根据分表策略从逻辑表中分出来的，每个真实表存储逻辑表的一部分数据。

如果逻辑表 user 根据用户 ID 分为三个真实表，那么 user_0, user_1, user_2 就是具有特定后缀的真实表的名称。
绑定表 (Binding Table): 绑定表是指一组逻辑表，它们之间有着相同的分片策略。在进行关联查询时，绑定表之间的数据分布方式保证了关联查询可以在相同的数据节点上执行，从而避免跨节点的关联操作，这有助于减少不必要的数据笛卡尔积和网络开销。

举例来说，如果 order 和 order_item 是绑定表，并且它们按照相同的订单 ID 进行分片，当你根据订单 ID 关联这两个表时，查询会自然地在相同分片上执行。
广播表 (Broadcast Table): 广播表是一个特殊的表，它的数据在所有的数据库实例中都是一样的。通常用于那些数据量小但需要频繁访问的公共数据，例如配置数据、字典数据等。

在分库的环境下，广播表会在每个数据库实例中都有一份完整的副本。例如，一个包含国家代码和名称的 country 表可能就是一个广播表，因为每个数据库实例都需要访问这些共享数据。