一. 在Docker中安装ShardingSphere

二实践：读写分离

2.1 应用场景

2.2 架构图

2.3 服务器规划

2.4 启动数据库服务器

2.5. 配置读写分离

2.6 日志配置

2.7 重启ShardingSphere

2.8 测试

2.9. 负载均衡

2.9.1. 随机负载均衡算法示例

2.9.2. 轮询负载均衡算法示例

2.9.3. 权重负载均衡算法示例

2.10 手动事务

一. 在Docker中安装ShardingSphere

接下来我将讲解ShardingSphere在Docker里面的安装

创建Docker容器所需的映射目录

我们必须提前进行创建

mkdir -p /bit/shardingsphere/proxy/conf
mkdir -p /bit/shardingsphere/proxy/ext-lib
mkdir -p /bit/shardingsphere/proxy/logs

创建Docker容器

这个 docker run 命令是用来安装并启动一个 ShardingSphere-Proxy 容器的。ShardingSphere-Proxy 是一个透明的数据库代理，它允许你像连接普通 MySQL 服务器一样连接它，但它背后可以管理多个数据库实例，实现分库分表、读写分离等高级功能。

docker run -d \-p 3307:3307 \-v /bit/shardingsphere/proxy/conf:/opt/shardingsphere-proxy/conf \-v /bit/shardingsphere/proxy/ext-lib:/opt/shardingsphere-proxy/ext-lib \-v /bit/shardingsphere/proxy/logs:/opt/shardingsphere-proxy/logs \-e JVM_OPTS="-Xms256m -Xmx256m -Xmn128m" \--name ss-proxy \apache/shardingsphere-proxy:5.3.2

这些参数啥意思呢？我们看看

docker run -d \

docker run：Docker 命令，用于创建并启动一个新的容器。
-d：表示以后台（detached）模式运行容器。容器启动后，命令行会立即返回，不会阻塞。

-p 3307:3307 \

-p：用于映射端口。
3307:3307：将宿主机（Host）的 3307 端口映射到容器（Container）内部的 3307 端口。这意味着，外部应用程序（如你的应用代码、MySQL 客户端工具）需要连接宿主机的 3307 端口来访问 ShardingSphere-Proxy 服务。

-v /bit/shardingsphere/proxy/conf:/opt/shardingsphere-proxy/conf \

-v：用于创建数据卷（Volume），实现宿主机目录与容器目录的绑定（挂载）。
/bit/shardingsphere/proxy/conf:/opt/shardingsphere-proxy/conf：将宿主机上的 /bit/shardingsphere/proxy/conf 目录挂载到容器内的 /opt/shardingsphere-proxy/conf 目录。这个目录通常存放 ShardingSphere-Proxy 的核心配置文件，如 server.yaml（服务配置）和 config-xxx.yaml（数据分片/读写分离规则配置）。通过挂载，你可以在宿主机上直接修改配置文件，而无需进入容器内部，修改后重启容器即可生效。

-v /bit/shardingsphere/proxy/ext-lib:/opt/shardingsphere-proxy/ext-lib \

/bit/shardingsphere/proxy/ext-lib:/opt/shardingsphere-proxy/ext-lib：将宿主机上的 /bit/shardingsphere/proxy/ext-lib 目录挂载到容器内的 /opt/shardingsphere-proxy/ext-lib 目录。这个目录用于存放用户自定义的 JAR 包，例如：
- 数据库驱动（如果官方镜像里没有你需要的数据库驱动，如 Oracle）。
- 自定义的分片算法类。
- 自定义的加密算法类。
- 自定义的分布式序列生成器。

-v /bit/shardingsphere/proxy/logs:/opt/shardingsphere-proxy/logs \

/bit/shardingsphere/proxy/logs:/opt/shardingsphere-proxy/logs：将宿主机上的 /bit/shardingsphere/proxy/logs 目录挂载到容器内的 /opt/shardingsphere-proxy/logs 目录。ShardingSphere-Proxy 的运行日志（如 shardingsphere.log）会输出到这个目录。挂载后，你可以在宿主机上方便地查看和管理日志文件，即使容器被删除，日志也保留在宿主机上。

-e JVM_OPTS="-Xms256m -Xmx256m -Xmn128m" \

-e：用于设置环境变量（Environment Variable）。
JVM_OPTS="-Xms256m -Xmx256m -Xmn128m"：将环境变量 JVM_OPTS 的值设置为指定的 JVM 内存参数。当 ShardingSphere-Proxy 启动时，会读取这个环境变量，并将其作为 JVM 的启动参数，从而控制其内存使用。

--name ss-proxy \

--name：为启动的容器指定一个名称。
ss-proxy：这个容器的名称被设置为 ss-proxy。之后你可以使用 docker stop ss-proxy, docker start ss-proxy, docker logs ss-proxy 等命令来管理这个容器，比使用容器的 ID 更方便。

apache/shardingsphere-proxy:5.3.2

apache/shardingsphere-proxy:5.3.2：这是要运行的 Docker 镜像的名称和标签。
- apache/shardingsphere-proxy 是镜像的名称。
- 5.3.2 是镜像的版本标签（Tag）。Docker 会首先检查本地是否有这个镜像，如果没有，会自动从 Docker Hub（或其他配置的镜像仓库）拉取这个版本的镜像，然后使用它来创建并启动容器。

废话不多说，我们直接执行就OK。

然后我们来看看有没有启动成功啊

# 查看是否启动成功
docker ps -a

我们发现没有启动成功，这个是因为docker容器没有进行配置

修改配置文件

首先我们需要来到这个配置文件对应的宿主机映射目录里面，也就是/bit/shardingsphere/proxy/conf

cd  /bit/shardingsphere/proxy/conf

我们就在这个目录里面创建一个配置文件server.yaml

vim server.yaml

然后把下面这个粘贴进去即可

# 运行模式配置
mode:type: Standalone  # 单机模式（非集群部署）# 用户权限配置
authority:users:- user: root@%          # 用户名格式：用户名@访问主机（%表示允许任意主机访问）password: 123456      # 用户密码privilege:type: ALL_PERMITTED     # 权限类型：授予该用户所有操作权限# 系统属性配置
props:sql-show: true  # 是否在日志中显示执行的SQL语句（true=显示，false=隐藏）proxy-mysql-default-version: 8.0.42  # 代理对外暴露的MySQL默认版本号

我们保存退出。

上传MySQL驱动

连接MySQL数据库时，需要把MySQL驱动包放入宿主机映射扩展目录/bit/shardingsphere/proxy/ext-lib中

cd /bit/shardingsphere/proxy/ext-lib

现在我们可以上一小节下载的 MySQL驱动驱动直接复制到这里即可。

当然，大家执行下面这个命令也是可以的

wget https://repo1.maven.org/maven2/com/mysql/mysql-connector-j/8.0.33/mysql-connector-j-8.0.33.jar

启动

启动Docker容器，运行ShardingSphere

# 重新启动容器
docker start ss-proxy
# 查看状态，启动成功
docker ps

没有一点问题

测试连接

通过客户端工具连接

# 指定主机和端口号进行连接，成功
mysql -uroot -p -h127.0.0.1 -P3307

进入Docker容器

# 进入容器
docker exec -it ss-proxy env LANG=C.UTF-8 /bin/bash

如果我们想要远程登陆这个服务器的话，需要去云服务器里面的防火墙和安全组里面开放这个3307端口。

二实践：读写分离

2.1 应用场景

当系统负载越来越大时，I/O作为整个系统的性能瓶颈就越来越明显，大量的数据库访问可能会把某个数据节点打爆(尤其是在单台数据库服务器的情况下)，通过部署读写分离可以有效的解决单点故障问题并提升系统性能。

有以下需求时可以使用读写分离架构部署数据库服务：

读多写少的场景：很多的应用程序都是读多写少的场景，读写分离可以将读请求分散到多个从服务器上，从而减轻主服务器的负担，显著提高读操作的性能。
水平扩展：通过增加从服务器的数量，可以进一步扩展数据库的读能力，以应对不断增长的负载。
故障转移：在主服务器发生故障时，可以快速将读和写操作切换到从服务器，保证服务的可用性。
实时备份：从服务器也可以作为主服务器的实时备份节点，当主服务器发生故障时，可以快速恢复数据。

2.2 架构图

采用一主两从的数据库集群架构

2.3 服务器规划

在单台服务器上使用 Docker 模拟多台服务器的场景

主从服务器IP一致，端口号不同

主服务器：容器名 bit-mysql-master 端口号 53306
从服务器1：容器名 bit-mysql-slavel，端口号 53307
从服务器2：容器名 bit-mysql-slave2，端口号 53308

我们已经在先前的文章里面实现了两个从节点对主节点的数据的实时复制，也就是所谓的主从复制，但是我们还没有实现读写分离，那么我们今天的读写分离主要是针对中间件——ShardingSphere-Proxy，我们通过配置ShardingSphere-Proxy即可在原来主从复制的基础之上完成读写分离。

注意：启动docker前先关闭防火墙
sudo systemctl status ufw

2.4 启动数据库服务器

注意：这里的主从复制配置我们已经完成，我们这里只检验一下主从复制机制是否正常运行而已，主从复制具体配置步骤请看：【 MySQL集群架构与实践2】高性能架构模式，ShardingSphere的安装-CSDN博客

首先启动主从节点的数据库服务器，保证主从节点正常工作.

具体怎么做呢？

先看看这些节点有没有在运行

docker ps

很好，都在运行，那么我们直接使用mysql去进行登陆即可

#登陆主节点
mysql -h127.0.0.1 -P53306 -uroot -p#登陆从节点1
mysql -h127.0.0.1 -P53307 -uroot -p#登陆从节点2
mysql -h127.0.0.1 -P53308 -uroot -p

这个时候我们需要检测一下主从复制机制还有没有在生效？

首先我们需要查看两个从节点的信息

我们在主节点执行一下DML语句

我们接着回去两个从节点看看有没有在进行同步复制

答案很明显了啊！！！我们的主从复制是没有问题的啊，下面我们就来进行配置读写分离

2.5. 配置读写分离

首先我们需要来到这个配置文件对应的宿主机映射目录里面，也就是/bit/shardingsphere/proxy/conf

cd /bit/shardingsphere/proxy/conf

接下来我们将创建一个文件 config-readwrite-splitting.yaml

vim config-readwrite-splitting.yaml

config-readwrite-splitting.yaml 在 ShardingSphere Proxy 中的作用是：定义读写分离规则，将数据库操作智能路由到主库（写操作）和从库（读操作），实现数据库负载均衡和高可用。

那这里面具体要填放什么东西呢？

我们去看看我们使用二进制发布包安装的 ShardingSphere Proxy里面的conf目录看看，那里也有一个config-readwrite-splitting.yaml，这个文件是系统提供给我们的模板，这个文件默认里面全是注释，我们只需要在它的基础之上进行修改即可。

在config-readwrite-splitting.yaml里面官方其实已经就帮我们写了一些模板，只不过默认是被注释掉了，我们只需要进去修改database-readwrite-splitting.yaml 配置文件即可

大家找到上面这个啊，那就是我们的模板啊。我们只需在这个模板上面做些修改即可。

databaseName: bit_proxy_dbdataSources:write_ds:url: jdbc:mysql://150.158.139.86:53306/bit_db?characterEncoding=utf8&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true&useSSL=falseusername: rootpassword: 123456connectionTimeoutMilliseconds: 30000idleTimeoutMilliseconds: 60000maxLifetimeMilliseconds: 1800000maxPoolSize: 50minPoolSize: 1read_ds_0:url: jdbc:mysql://150.158.139.86:53307/bit_db?characterEncoding=utf8&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true&useSSL=falseusername: rootpassword: 123456connectionTimeoutMilliseconds: 30000idleTimeoutMilliseconds: 60000maxLifetimeMilliseconds: 1800000maxPoolSize: 50minPoolSize: 1read_ds_1:url: jdbc:mysql://150.158.139.86:53308/bit_db?characterEncoding=utf8&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true&useSSL=falseusername: rootpassword: 123456connectionTimeoutMilliseconds: 30000rules:
- !READWRITE_SPLITTINGdataSources:readwrite_ds:staticStrategy:writeDataSourceName: write_dsreadDataSourceNames:- read_ds_0- read_ds_1# loadBalancerName: weight    # 负载均衡策略名 以下分别是：权重，轮询，随机# loadBalancerName: round_robinloadBalancerName: randomloadBalancers:random:type: RANDOMround_robin:type: ROUND_ROBINweight:type: WEIGHTprops:read_ds_0: 2.0read_ds_1: 1.0

注意：这里特别容易出问题，所以我推荐大家去官网使用官方的配置：shardingsphere/examples/shardingsphere-proxy-example/shardingsphere-proxy-boot-mybatis-example/src/main/resources/conf/config-readwrite-splitting.yaml at 5.3.2 · apache/shardingsphere · GitHub

url中最重要的是IP地址，端口号，数据库名

我们保存退出。

我们这里就是配置数据源的问题，让ShardingSphere知道哪个是主节点，哪个是从节点。

2.6 日志配置

首先我们需要来到这个配置文件对应的宿主机映射目录里面，也就是/bit/shardingsphere/proxy/conf

cd /bit/shardingsphere/proxy/conf

接下来我们将创建一个文件

vim logback.xml

并编写以下内容

<?xml version="1.0"?>
<configuration><!-- 日志输入到文件 --><appender name="SHARDING_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"><!-- 日志路径 --><file>./logs/shardingsphere.log</file><encoder><!-- 日志输入的样式 --><pattern>[%-5level] %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern></encoder><rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"><fileNamePattern>shardingsphere.%d{yyyy-MM-dd}.%i.log</fileNamePattern><timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"><maxFileSize>100MB</maxFileSize></timeBasedFileNamingAndTriggeringPolicy></rollingPolicy></appender><root level="INFO"><appender-ref ref="SHARDING_FILE" /></root></configuration>

我们保存退出一下。

2.7 重启ShardingSphere

# 重新启动ShardingSphere的Docker容器
docker restart ss-proxy# 查看容器是否启动成功
docker ps

# 使用客户端连接ShardingSphere
mysql -h150.158.139.86 -P3307 -uroot -p

我们可以进去看看

我们看看里面的内容

2.8 测试

我们可以去宿主机映射的目录/bit/shardingsphere/proxy/logs打开实时日志

# 进入容器
cd /bit/shardingsphere/proxy/logs# 查看ShardingSphere的实时日志
tail -f shardingsphere.log

删除数据

日志里面就多了下面

[INFO ] 2025-07-31 02:54:23.319 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Logic SQL: delete from t_user where id=4

[INFO ] 2025-07-31 02:54:23.321 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Actual SQL: write_ds ::: delete from t_user where id=4

这就说明删除操作是在主节点进行操作的

写入数据

执行INSERT语句写入一条数据

-- 客户端执行INSERT语句，写入一和数据
insert into t_user (name) values ('test');

日志中显示如下信息：

[INFO ] 2025-07-31 02:56:17.640 [ShardingSphere-Command-2] INFO ShardingSphere-SQL - Logic SQL: insert into t_user (name) values ('test')

[INFO ] 2025-07-31 02:56:17.640 [ShardingSphere-Command-2] INFO ShardingSphere-SQL - Actual SQL: write_ds ::: insert into t_user (name) values ('test')

补充一下：

Logic SQL是客户端发来的语句
Actual SQL是ShardingSphere根据配置的规则发送到某一个具体的节点上执行的语句

这就说明insert是在主节点进行操作的

查询数据

多次执行SELECT语句进行查询

-- 执行两次
select * from t_user;select * from t_user;

在日志中显示如下信息：

# 第一次查询

[INFO ] 2025-07-31 02:59:23.958 [ShardingSphere-Command-3] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 02:59:23.958 [ShardingSphere-Command-3] INFO ShardingSphere-SQL - Actual SQL: read_ds_0 ::: select * from t_user

# 第二次查询

[INFO ] 2025-07-31 02:59:26.853 [ShardingSphere-Command-3] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 02:59:26.854 [ShardingSphere-Command-3] INFO ShardingSphere-SQL - Actual SQL: read_ds_1 ::: select * from t_user

这就说明select是在两个从节点进行操作的

现在就说明，我们的读写分离已经完成了。

2.9. 负载均衡

ShardingSphere 内置提供了多种负载均衡算法，具体包括轮询算法、随机访问算法和权重访问算法，能够满足用户绝大多数业务场景的需要.

轮询负载均衡算法类型：ROUND_ROBIN

根据请求次数和服务器数量进行负载均衡。

随机负载均衡算法类型：RANDOM

请求具体发送到哪个真实的服务器不确定，完全随机，负载不易控制。

这个其实是不会使用的。

权重负载均衡算法类型：WEIGHT

不同的服务器配置不同的权重，权重大的负载高，可以根据服务器的硬件指定合适的权重。

权重负载均衡算法可配置属性：

属性名称	数据类型	说明
${replica-name}	double	属性名使用读库名称，参数填写读库对应的权重值。权重≥0，合计≤Double.MAX_VALUE

config-readwrite-splitting.yaml的部分配置示例：

rules:
- !READWRITE_SPLITTING  # 声明读写分离规则dataSources:readwrite_ds:  # 读写分离数据源名称staticStrategy:  # 静态策略（非动态发现）writeDataSourceName: write_ds  # 写操作专用数据源readDataSourceNames:           # 读操作数据源列表- read_ds_0  # 读库实例1- read_ds_1  # 读库实例2loadBalancerName: weight  # 指定读库使用的负载均衡器（指向下方定义的weight配置）# ==================== 负载均衡器配置 ====================loadBalancers:# 可选算法1：随机选择random:type: RANDOM  # 随机算法，每次从读库中随机选择一个# 可选算法2：轮询选择round_robin: type: ROUND_ROBIN  # 轮询算法，按顺序依次选择读库# 实际使用的算法：加权负载均衡weight:type: WEIGHT  # 加权算法，根据权重分配读请求props:        # 权重配置（必须与readDataSourceNames中的名称匹配）read_ds_0: 2.0  # 读库1的权重值（数值越大被选中的概率越高）read_ds_1: 1.0  # 读库2的权重值# 权重计算逻辑：#   read_ds_0概率 = 2.0/(2.0+1.0) ≈ 66.7%#   read_ds_1概率 = 1.0/(2.0+1.0) ≈ 33.3%

上面这个例子里现在就是使用了加权负载均衡算法。（因为loadBalancerName: weight）

在上面这个例子里如果说loadBalancerName: random，则是使用随机负载均衡算法

上面这个例子里loadBalancerName:round_robin，则是使用轮询负载均衡算法

2.9.1. 随机负载均衡算法示例

我们回到上面我们配置的 /bit/shardingsphere/proxy/conf/config-readwrite-splitting.yaml文件里面看看

      loadBalancerName: randomloadBalancers:random:type: RANDOMround_robin:type: ROUND_ROBINweight:type: WEIGHTprops:read_ds_0: 2.0read_ds_1: 1.0

我们之前使用的是随机负载均衡算法啊！！

2.9.2. 轮询负载均衡算法示例

我们还是来到配置文件的目录下面

我们进去config-readwrite-splitting.yaml，修改成轮询负载均衡算法

接下来我们重启一下我们的容器

docker restart ss-proxy
docker ps

接下来我们还是去看看日志

tail -f /bit/shardingsphere/proxy/logs

接着我们换一个终端来登录我们的mysql服务器

mysql -h127.0.0.1 -P3307 -uroot -p

接着我们看看

写入

insert into t_user(name) values ('test05');

日志里多了这两句

[INFO ] 2025-07-31 03:55:27.393 [ShardingSphere-Command-2] INFO ShardingSphere-SQL - Logic SQL: insert into t_user(name) values ('test05')

[INFO ] 2025-07-31 03:55:27.393 [ShardingSphere-Command-2] INFO ShardingSphere-SQL - Actual SQL: write_ds ::: insert into t_user(name) values ('test05')

写入都在读节点。

查询

select * from t_user;

第一次查询

[INFO ] 2025-07-31 04:03:52.520 [ShardingSphere-Command-3] INFO ShardingSphere-SQL - Logic SQL: select * from t_user

[INFO ] 2025-07-31 04:03:52.520 [ShardingSphere-Command-3] INFO ShardingSphere-SQL - Actual SQL: read_ds_1 ::: select * from t_user

第二次查询

[INFO ] 2025-07-31 04:05:05.362 [ShardingSphere-Command-3] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 04:05:05.362 [ShardingSphere-Command-3] INFO ShardingSphere-SQL - Actual SQL: read_ds_0 ::: select * from t_user

第三次查询

[INFO ] 2025-07-31 04:05:39.234 [ShardingSphere-Command-3] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 04:05:39.234 [ShardingSphere-Command-3] INFO ShardingSphere-SQL - Actual SQL: read_ds_1 ::: select * from t_user

第四次查询

[INFO ] 2025-07-31 04:05:41.564 [ShardingSphere-Command-3] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 04:05:41.564 [ShardingSphere-Command-3] INFO ShardingSphere-SQL - Actual SQL: read_ds_0 ::: select * from t_user

很标准的轮询啊

2.9.3. 权重负载均衡算法示例

我们还是来到配置文件的目录下面

我们进去config-readwrite-splitting.yaml，修改成权重负载均衡算法示例

接下来我们重启一下我们的容器

docker restart ss-proxy
docker ps

接下来我们还是去看看日志

tail -f /bit/shardingsphere/proxy/logs

接着我们换一个终端来登录我们的mysql服务器

mysql -h127.0.0.1 -P3307 -uroot -p

接着我们看看

写入

insert into t_user(name) values ('test06');

日志里多了这两句

[INFO ] 2025-07-31 07:25:23.859 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Logic SQL: insert into t_user(name) values ('test06')

[INFO ] 2025-07-31 07:25:23.860 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Actual SQL: write_ds ::: insert into t_user(name) values ('test06')

写入都在读节点。

查询

select * from t_user;

第一次查询

[INFO ] 2025-07-31 07:25:51.789 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 07:25:51.789 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Actual SQL: read_ds_0 ::: select * from t_user

第二次查询

[INFO ] 2025-07-31 07:25:54.740 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 07:25:54.741 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Actual SQL: read_ds_0 ::: select * from t_user

第三次查询

[INFO ] 2025-07-31 07:25:55.594 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 07:25:55.595 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Actual SQL: read_ds_0 ::: select * from t_user

第四次查询

[INFO ] 2025-07-31 07:25:56.125 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 07:25:56.125 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Actual SQL: read_ds_0 ::: select * from t_user

第五次查询

[INFO ] 2025-07-31 07:25:57.048 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 07:25:57.048 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Actual SQL: read_ds_0 ::: select * from t_user

第六次查询

[INFO ] 2025-07-31 07:25:57.566 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 07:25:57.567 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Actual SQL: read_ds_1 ::: select * from t_user

第七次查询

[INFO ] 2025-07-31 07:25:59.127 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 07:25:59.130 [ShardingSphere-Command-1] INFO ShardingSphere-SQL - Actual SQL: read_ds_0 ::: select * from t_user

我们看到大部分情况都是从节点1在执行这个查询业务，只有少部分情况才会是从节点2在执行

2.10 手动事务

-- 开始事务
start transaction;-- 插入一条数据
insert into t_user (name) values ('transaction');-- 查询
select * from t_user;-- 回滚，结束事务
rollback;-- 再次查询
select * from t_user;

日志中显示如下信息：

#写入操作

[INFO ] 2025-07-31 07:30:20.112 [ShardingSphere-Command-2] INFO ShardingSphere-SQL - Logic SQL: insert into t_user (name) values ('transaction')
[INFO ] 2025-07-31 07:30:20.112 [ShardingSphere-Command-2] INFO ShardingSphere-SQL - Actual SQL: write_ds ::: insert into t_user (name) values ('transaction')

#事务中查询

[INFO ] 2025-07-31 07:30:27.936 [ShardingSphere-Command-2] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 07:30:27.937 [ShardingSphere-Command-2] INFO ShardingSphere-SQL - Actual SQL: write_ds ::: select * from t_user

#事务后查询

[INFO ] 2025-07-31 07:30:40.634 [ShardingSphere-Command-2] INFO ShardingSphere-SQL - Logic SQL: select * from t_user
[INFO ] 2025-07-31 07:30:40.634 [ShardingSphere-Command-2] INFO ShardingSphere-SQL - Actual SQL: read_ds_1 ::: select * from t_user

我们发现事务中的查询可是在写服务器里执行的。