分库分表看这一篇就够了：Sharding-Proxy

分库分表看这一篇就够了：Sharding-Proxy

前言

---

Sharding-Proxy

Sharding-Proxy 是 Apache ShardingSphere 项目的一部分，它是一个透明的数据库代理，位于应用程序和数据库之间。它的主要功能是将SQL请求路由到正确的分片（即具体的数据库实例或表），并汇总结果返回给客户端。 Sharding-Proxy 提供了类似于传统数据库的服务接口，使得应用程序无需修改即可连接到分片后的数据库集群。

Sharding-Proxy 的特点：

• 透明性：对应用程序来说， Sharding-Proxy 就像是一个普通的数据库服务器，应用程序可以通过标准的 JDBC 、 MySQL 协议等与之通信。
• 高可用性：支持多节点部署，提供负载均衡和故障转移机制。
• SQL解析与优化：能够解析 SQL 语句，执行分片路由、读写分离等功能，并对查询进行优化。
• 数据加密：可以配置数据传输过程中的加密选项，保障数据安全。
• 权限管理：内置用户认证和权限控制功能，保护数据库访问的安全性。

Sharding-JDBC

Sharding-JDBC 同样是 Apache ShardingSphere 的一部分，它要早于 Sharding-Proxy。它是一个 Java 库，直接嵌入到应用程序中作为 JDBC 驱动使用。它通过拦截 JDBC 调用，在应用层面上实现 SQL 解析、分片路由等功能。 Sharding-JDBC 对应用程序的侵入性上，比 Sharding-Proxy 要高一些。但 Sharding-JDBC 也有它自己的优点和应用场景。

Sharding-JDBC 的特点：

• 轻量级：由于是基于 JDBC 的解决方案，因此非常轻量，易于集成到现有的Java应用中。
• 灵活性：可以直接在应用程序代码中配置分片规则，允许更细粒度地控制分片行为。
• 兼容性：几乎兼容所有支持 JDBC 的数据源，包括但不限于 MySQL、 PostgreSQL 等。
• 性能：因为是在应用层面处理分片逻辑，所以减少了网络开销，理论上可以获得更好的性能表现。

二者区别

特性/方面	Sharding-Proxy	Sharding-JDBC
位置	数据库与客户端之间	应用程序内部
部署方式	独立部署为服务端	嵌入式库，集成到应用程序中
适用场景	适用于多种编程语言和框架的应用	主要针对Java应用
配置复杂度	相对较高，需要额外管理和维护	较低，直接在应用中配置
透明程度	对应用程序完全透明	应用程序需要引入依赖
扩展性	支持水平扩展，多节点部署	扩展性受限于单个应用实例
性能开销	可能增加一次网络跳转	减少了网络跳转次数
安全性	内置用户认证和权限控制	依赖应用层面的安全措施

小结一下，对性能有要求且允许 Sharding-JDBC侵入到自己的应用服务里，使用Sharding-JDBC作为分库分表的工具；对性能没有要求，但是对部署有扩展要求，或者希望部署异构的数据库连接，那么使用Sharding-Proxy更合适。

因为在部署配置上， Sharding-Proxy 和 Sharding-JDBC 大同小异，所以本文的后半部分重点介绍 Sharding-Proxy 。

部署

---

使用限制

ShardingSphere-Proxy 对图形化数据库客户端的支持有限，在使用时可能会出现一些错误提示或者确实部分功能。但是在命令行客户端使用上，没有这些问题。

限制一

比如，查看单表数据时，会报错。这是因为连接 ShardingSphere-Proxy 时，我们看到的 t_order 表是一个逻辑表，实际的表名可能是 t_order_0 和 t_order_1 。在查询逻辑表时，必须带上分片条件。

SQL 错误 [20090] [42000]: Not allow DML operation without sharding conditions.

order_id 是配置的分片键。

这就会有一个问题，如何查询 t_order 表的全量数据？

ShardingSphere-Proxy提供了 SQL Hint 作为 SQL 语法的补充。当要查询 t_order表的全量数据时，可以使用如下 sql 。 sharding_key_required_auditor表示禁用 SQL审计。

/* SHARDINGSPHERE_HINT: disableAuditNames=sharding_key_required_auditor */ 
select * from t_order;

此时就可以查询t_order所有的数据了。如下图中，有两个 order_id=4的数据，它们分别来自于不同的实际表。

如果是使用命令行客户端，需要在登录时添加 -c 选项保留注释

# 3307 是 ShardingSphere-Proxy 默认端口
mysql -h{HOST_IP} -u{user} -p{password} -P3307 -c

SQL HINT其他用法详见：

SQL Hint :: ShardingSphere

限制二

在 DBeaver中，是看不到表的列字段的，所以无法通过图形化界面增删改字段。不过对于程序员来说使用 Alter Table 语法对字段进行增删改应该是没有压力。

表的DDL结构可以正常显示。

还有一些其他的功能限制，后面如果发现了我再进行补充。

前提条件

使用 Docker 启动 ShardingSphere-Proxy 无须额外依赖。

使用二进制分发包启动 Proxy，需要环境具备 Java JRE 8 或更高版本。

下载

我使用的是 5.5.1 版本的 ShardingSphere-Proxy 。下载地址如下：

wget https://archive.apache.org/dist/shardingsphere/5.5.1/apache-shardingsphere-5.5.1-shardingsphere-proxy-bin.tar.gz
tar -zxvf apache-shardingsphere-5.5.1-shardingsphere-proxy-bin.tar.gz -C /ops/app
mv /ops/app/apache-shardingsphere-5.5.1-shardingsphere-proxy /ops/app/sharding-proxy

其他版本的下载地址如下：

https://archive.apache.org/dist/shardingsphere/

使用默认配置

在使用默认配置之前，最好备份一下。

cp global.yaml global.yaml.bak
cp database-sharding.yaml database-sharding_db.yaml.bak

配置 global.yaml

模式配置

global.yaml主要是进行通用配置，如模式、用户权限等。我因为是在本地部署，所以使用了 Standalone单机部署。如果是生产环境，推荐使用 Cluster集群部署。

mode:
  type: Standalone
  repository:
    type: JDBC
    
authority:
  users:
    - user: root@127.0.0.1
      password: 123456
    - user: sharding
      password: 123456
  privilege:
    type: ALL_PERMITTED

模式配置示例详见：模式配置 :: ShardingSphere

认证和授权

authority 用来配置认证和授权信息。认证信息在 users 配置下填写用户名和密码。授权信息在 privilege 下配置，有两种权限提供者：

• ALL_PERMITTED：每个用户都拥有所有权限，无需专门授权；（将在未来版本中删除）
• DATABASE_PERMITTED：为用户授予指定逻辑库的权限，通过 user-database-mappings 进行定义。（推荐使用）

DATABASE_PERMITTED 示例：

authority:
  users:
     - user: root@127.0.0.1
	     password: 123456
     - user: sharding
       password: 123456
  privilege:
    type: DATABASE_PERMITTED
    props:
      user-database-mappings: sharding@%=*, test@%=sharding_db, test@%=test_db

授权sharding@% 用户访问所有逻辑库 (*) ；授权 test@% 用户只能访问 sharding_db 和 test_db。

配置示例详见：认证和授权 :: ShardingSphere

配置 database-sharding_db.yaml

首先从整体上观察一下真实 MySQL数据库和虚拟的 ShardingSphere-Proxy 数据源。

• 真实 MySQL数据库

• 虚拟的 ShardingSphere-Proxy 数据源

数据源配置

databaseName: sharding_db

dataSources:
  ds_0:
    url: jdbc:mysql://{IP}:3306/demo_ds_0?useSSL=false
    username: sharding   # mysql客户端登录账号使用此账户
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
    minPoolSize: 1
  ds_1:
    url: jdbc:mysql://{IP}:3306/demo_ds_1?useSSL=false
    username: sharding
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
    minPoolSize: 1

需要注意的是， sharding_db 是一个逻辑库的名称， ds_0 和 ds_1 是数据源的逻辑名称，在后文的规则配置中会使用到。

demo_ds_0 和 demo_ds_1 则是物理数据库中真实存在的，如果不存在，启动 ShardingSphere-Proxy 时会出现报错信息。这里连接两个库的端口是 3306，而非 3307，因为连接的是真实的 MySQL数据库。

详见：数据源配置 :: ShardingSphere

规则配置

规则配置主要是用来描述分片规则之间的依赖关系。 ShardingSphere 会根据 YAML 配置，自动完成逻辑数据源的创建。

t_order 配置 ds_${0..1}.t_order_${0..1} ，表示逻辑数据源 t_order 映射到 ds_0 或 ds_1 数据源下的 t_order_0 或 t_order_1 物理表。

0 和 1 的路由算法配置在 shardingAlgorithmName 里。例如表的分片算法配置的是 t_order_inline ，t_order_inline 的算法表达式 t_order_${order_id % 2} 表示路由到表前缀为 t_order_ 的表，且后缀序号根据 {order_id % 2} 而来（order_id字段对 2 取模）。所以物理表必须存在 order_id 字段，否则会报错。

同理，数据源的路由算法也是同样的配置，算法表达式 algorithm-expression: ds_${user_id % 2} 表示通过 user_id 字段取模来路由，所以 user_id 字段必须存在。

rules:
- !SHARDING
  tables:
    t_order:
      actualDataNodes: ds_${0..1}.t_order_${0..1}
      tableStrategy:
        standard:
          shardingColumn: order_id
          shardingAlgorithmName: t_order_inline
      keyGenerateStrategy:
        column: order_id
        keyGeneratorName: snowflake
      auditStrategy:
        auditorNames:
          - sharding_key_required_auditor
        allowHintDisable: true
    t_order_item:
      actualDataNodes: ds_${0..1}.t_order_item_${0..1}
      tableStrategy:
        standard:
          shardingColumn: order_id
          shardingAlgorithmName: t_order_item_inline
      keyGenerateStrategy:
        column: order_item_id
        keyGeneratorName: snowflake
  bindingTables:
    - t_order,t_order_item
  defaultDatabaseStrategy:
    standard:
      shardingColumn: user_id
      shardingAlgorithmName: database_inline
  defaultTableStrategy:
    none:
  defaultAuditStrategy:
    auditorNames:
      - sharding_key_required_auditor
    allowHintDisable: true

  shardingAlgorithms:
    database_inline:
      type: INLINE
      props:
        algorithm-expression: ds_${user_id % 2}
        #allow-range-query-with-inline-sharding: true
    t_order_inline:
      type: INLINE
      props:
        algorithm-expression: t_order_${order_id % 2}
    t_order_item_inline:
      type: INLINE
      props:
        algorithm-expression: t_order_item_${order_id % 2}

  keyGenerators:
    snowflake:
      type: SNOWFLAKE

  auditors:
    sharding_key_required_auditor:
      type: DML_SHARDING_CONDITIONS

- !BROADCAST
  tables:
    - t_address

详见：数据分片 :: ShardingSphere

引入MySQL依赖

在 sharding-proxy 路径下新建 ext-lib 目录，将 mysql-connector-java-8.0.11.jar 驱动包放进来。

如果是 PostgreSQL 数据库，可以省略此步。

启动/停止服务

# 启动
/ops/app/sharding-proxy/bin/start.sh

# 停止
/ops/app/sharding-proxy/bin/stop.sh

使用 ShardingSphere-Proxy

---

本文将创建两个库，每个库各一个订单子表（ t_order_0、t_order_1 ）和订单项子表（ t_order_item_0、t_order_item_1 ），以此为例对 ShardingSphere-Proxy 做进一步的功能性探索。

准备真实库表

创建第一个分库（ demo_ds_0 ）及其分表，DDL 如下：

CREATE DATABASE `demo_ds_0` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */ /*!80016 DEFAULT ENCRYPTION='N' */;

-- demo_ds_0.t_order_0 definition
CREATE TABLE `t_order_0` (
  `order_id` bigint NOT NULL AUTO_INCREMENT,
  `order_name` varchar(100) COLLATE utf8mb4_bin DEFAULT NULL,
  `total_money` varchar(100) COLLATE utf8mb4_bin DEFAULT NULL,
  `user_id` bigint NOT NULL,
  PRIMARY KEY (`order_id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

-- demo_ds_0.t_order_1 definition
CREATE TABLE `t_order_1` (
  `order_id` bigint NOT NULL AUTO_INCREMENT,
  `order_name` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL,
  `total_money` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL,
  `user_id` bigint NOT NULL,
  PRIMARY KEY (`order_id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

-- demo_ds_0.t_order_item_0 definition
CREATE TABLE `t_order_item_0` (
  `order_item_id` bigint NOT NULL AUTO_INCREMENT,
  `order_id` bigint NOT NULL,
  `item_name` varchar(100) COLLATE utf8mb4_bin DEFAULT NULL,
  `item_desc` varchar(100) COLLATE utf8mb4_bin DEFAULT NULL,
  `user_id` bigint NOT NULL,
  PRIMARY KEY (`order_item_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

-- demo_ds_0.t_order_item_1 definition
CREATE TABLE `t_order_item_1` (
  `order_item_id` bigint NOT NULL AUTO_INCREMENT,
  `order_id` bigint NOT NULL,
  `item_name` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL,
  `item_desc` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL,
  `user_id` bigint NOT NULL,
  PRIMARY KEY (`order_item_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

创建第二个分库（ demo_ds_1 ）及其分表，DDL 如下：

CREATE DATABASE `demo_ds_1` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */ /*!80016 DEFAULT ENCRYPTION='N' */;

-- demo_ds_1.t_order_0 definition
CREATE TABLE `t_order_0` (
  `order_id` bigint NOT NULL AUTO_INCREMENT,
  `order_name` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL,
  `total_money` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL,
  `user_id` bigint NOT NULL,
  PRIMARY KEY (`order_id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

-- demo_ds_1.t_order_1 definition
CREATE TABLE `t_order_1` (
  `order_id` bigint NOT NULL AUTO_INCREMENT,
  `order_name` varchar(100) COLLATE utf8mb4_bin DEFAULT NULL,
  `total_money` varchar(100) COLLATE utf8mb4_bin DEFAULT NULL,
  `user_id` bigint NOT NULL,
  PRIMARY KEY (`order_id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

-- demo_ds_1.t_order_item_0 definition
CREATE TABLE `t_order_item_0` (
  `order_item_id` bigint NOT NULL AUTO_INCREMENT,
  `order_id` bigint NOT NULL,
  `item_name` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL,
  `user_id` bigint NOT NULL,
  PRIMARY KEY (`order_item_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

-- demo_ds_1.t_order_item_1 definition
CREATE TABLE `t_order_item_1` (
  `order_item_id` bigint NOT NULL AUTO_INCREMENT,
  `order_id` bigint NOT NULL,
  `item_name` varchar(100) COLLATE utf8mb4_bin DEFAULT NULL,
  `item_desc` varchar(100) COLLATE utf8mb4_bin DEFAULT NULL,
  `user_id` bigint NOT NULL,
  PRIMARY KEY (`order_item_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

订单表和订单项表在 ShardingSphere-Proxy 的概念中叫做绑定表，绑定表值分片规则一致的一组分片表。使用绑定表进行多表关联查询时，必须使用分片键进行关联，否则会出现笛卡尔积关联或跨库关联，从而影响查询效率。例如订单表和订单项表的分片键是 order_id 。

客户端连接

# {IP} 替换成自己的 ShardingSphere-Proxy 地址
mysql -h{IP} -usharding -p123456 -P3307 -c

连接命令行客户端，端口使用大写 -P 参数， 3307 是ShardingSphere-Proxy默认端口， -c 表示保留注释。

进入命令行，查看数据库。

上图可以看到数据库里多了一个 sharding_db ，这个库是我们在配置里配置的数据库名称。而我们自己创建的数据库则没有看到了。我们连接 3306 端口看下真实的 MySQL 数据库，对比一下。下图中没有了 sharding_db ，多了两个真实库 demo_ds_0 和 demo_ds_1 。

DDL操作

连接 ShardingSphere-Proxy 客户端，看看执行 DDL 操作会对真实库产生什么样的影响。

创建表

在ShardingSphere-Proxy 客户端下执行如下 SQL，创建 10 张表，表名后缀递增。

CREATE TABLE `t_test_0` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(100) COLLATE utf8mb4_bin DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

sharding_db 数据库如下图所示：

两个真实数据库如下图所示：

可以发现在 ShardingSphere-Proxy 客户端下创建的表，在两个真实库里是随机安排的。

因此，如果想要创建的表不需要分库分表，可以在 MySQL客户端或者ShardingSphere-Proxy 客户端执行创建 SQL ；如果想要创建的表需要分库分表，则最好在 MySQL客户端创建，并且需要修改 database-sharding.yaml配置，然后重启 ShardingSphere-Proxy服务。

删除表

在ShardingSphere-Proxy客户端执行删表 SQL ，成功在逻辑库和真实库都删除了 t_order_item 表。

drop table t_order_item;

表索引

在ShardingSphere-Proxy客户端执行创建普通索引SQL 。

-- 创建索引
ALTER TABLE `t_order_item` ADD INDEX `idx_user_id`(`user_id`) USING BTREE;
-- 删除索引
DROP INDEX idx_user_id ON t_order_item;

同样在逻辑库和真实库的 t_order_item 表都创建了索引。删除索引也是一样的。

新增表字段

在ShardingSphere-Proxy客户端执行创建表字段SQL 。在逻辑库和真实库的 t_order_item 表都创建了 order_amount 字段。

ALTER TABLE t_order_item ADD COLUMN order_amount  decimal DEFAULT NULL;

删除表字段

在ShardingSphere-Proxy客户端执行删除表字段SQL 。在逻辑库和真实库的 t_order_item 表都删除了 order_amount 字段。

ALTER TABLE t_order_item DROP COLUMN order_amount;

修改表字段

在ShardingSphere-Proxy客户端执行修改表字段SQL 。在逻辑库和真实库的 t_order_item 表都将 item_name 字段长度增加到 200 。

ALTER TABLE t_order_item modify column `item_name` varchar(200)  DEFAULT NULL;

DML操作

插入数据

在ShardingSphere-Proxy客户端执行插入数据SQL 。

INSERT INTO t_order (order_name,total_money,user_id) VALUES ('666','666',1);

先查询逻辑库里的 t_order 表，知道自动生成的主键 order_id 字段是按照雪花算法生成的，雪花算法在 database-sharding_db.yaml 配置文件的规则 keyGeneratorName 配置的，并没有按照表主键的 AUTO_INCREMENT 自增规则创建，这一点要注意一下！

keyGeneratorName 默认只支持两种类型： snowflake 和 uuid 。不支持自增主键的原因可能是在分表的场景里自增主键很容易冲突吧。

因为user_id = 1 ，对 2 取模得到 1 ，所以去 demo_ds_1 分库里查找新增的记录。

生成的 order_id = 1073543921063165952 ，对 2 取模得到 0 ，所以要去 t_order_0 分表里查找新增的记录。

select * from demo_ds_1.t_order_0;

删除数据

在ShardingSphere-Proxy客户端执行删除数据SQL 。

delete from t_order where order_id = 1073543921063165952;

上一节插入的数据，现在在真实库里已经被删除了。

修改数据

在ShardingSphere-Proxy客户端执行修改数据SQL 。

update t_order set order_name = '222_modified' where order_id = 2;

真实库里的 order_name 字段值由 222 变为了 222_modified 。

查询数据

查询数据前文已经提到过，如果在逻辑库里想要查询所有分库分表的数据，必须加上 SQL HINT 。不加 SQL HINT 就需要在查询条件里明确指出分片键的条件，例如 **where** ***order_id*** = 5 。

/* SHARDINGSPHERE_HINT: disableAuditNames=sharding_key_required_auditor */ 
select * from t_order;

需要指出的是，ShardingSphere-Proxy的逻辑表里并没有严格限定主键 order_id 的唯一性，所以在查询的时候会出现如下图一样查出来两个同样主键的记录。所以在写数据的时候，最好使用ShardingSphere-Proxy的雪花算法自动生成，而不要自己手动去添加主键。

国产化可行性分析

---

国产化数据库我选择达梦数据库，先将达梦数据库的环境部署一下。

Docker方式安装

产品下载-达梦数据

将下载好的 tar 包放到 /opt/dm8/ 目录下，加载此镜像包。

docker load < /opt/dm8/dm8_20241022_x86_rh6_64_single.tar

查看镜像

docker images

启动容器，主要启动参数如下：

• 宿主机端口 30236 映射容器端口 5236
• 宿主机数据保存地址 /opt/data 映射容器数据地址 /opt/dmdbms/data
• {image id} 是 镜像 id，替换成 docker images 查询出来的 镜像 id 或者 REPOSITORY:TAG

docker run -d -p 30236:5236 --restart=always --name=dm8_test --privileged=true -e LD_LIBRARY_PATH=/opt/dmdbms/bin -e PAGE_SIZE=16 -e EXTENT_SIZE=32 -e LOG_SIZE=1024 -e UNICODE_FLAG=1  -e INSTANCE_NAME=dm8_test -v /opt/data:/opt/dmdbms/data {image id}

客户端默认连接账号： SYSDBA/SYSDBA001

初始化表空间和表

-- 表空间 demo_ds_0
CREATE TABLE "demo_ds_0".T_ORDER_0 (
	ORDER_ID BIGINT NOT NULL AUTO_INCREMENT,
	ORDER_NAME VARCHAR(100) NULL,
	TOTAL_MONEY VARCHAR(100) NULL,
	USER_ID BIGINT NOT NULL,
	CONSTRAINT T_ORDER_0_PK PRIMARY KEY (ORDER_ID)
);

CREATE TABLE "demo_ds_0".T_ORDER_1 (
	ORDER_ID BIGINT NOT NULL AUTO_INCREMENT,
	ORDER_NAME VARCHAR(100) NULL,
	TOTAL_MONEY VARCHAR(100) NULL,
	USER_ID BIGINT NOT NULL,
	CONSTRAINT T_ORDER_1_PK PRIMARY KEY (ORDER_ID)
);

CREATE TABLE "demo_ds_0".T_ORDER_ITEM_0 (
	ORDER_ITEM_ID bigint NOT NULL AUTO_INCREMENT,
	ORDER_ID bigint NOT NULL,
	ITEM_NAME varchar(100) NULL,
	ITEM_DESC varchar(100) NULL,
	USER_ID bigint NOT NULL,
	CONSTRAINT T_ORDER_ITEM_0_PK PRIMARY KEY (ORDER_ITEM_ID)
);

CREATE TABLE "demo_ds_0".T_ORDER_ITEM_1 (
	ORDER_ITEM_ID bigint NOT NULL AUTO_INCREMENT,
	ORDER_ID bigint NOT NULL,
	ITEM_NAME varchar(100) NULL,
	ITEM_DESC varchar(100) NULL,
	USER_ID bigint NOT NULL,
	CONSTRAINT T_ORDER_ITEM_1_PK PRIMARY KEY (ORDER_ITEM_ID)
);

-- 表空间 demo_ds_1
CREATE TABLE "demo_ds_1".T_ORDER_0 (
	ORDER_ID BIGINT NOT NULL AUTO_INCREMENT,
	ORDER_NAME VARCHAR(100) NULL,
	TOTAL_MONEY VARCHAR(100) NULL,
	USER_ID BIGINT NOT NULL,
	CONSTRAINT T_ORDER_0_PK PRIMARY KEY (ORDER_ID)
);

CREATE TABLE "demo_ds_1".T_ORDER_1 (
	ORDER_ID BIGINT NOT NULL AUTO_INCREMENT,
	ORDER_NAME VARCHAR(100) NULL,
	TOTAL_MONEY VARCHAR(100) NULL,
	USER_ID BIGINT NOT NULL,
	CONSTRAINT T_ORDER_1_PK PRIMARY KEY (ORDER_ID)
);

CREATE TABLE "demo_ds_1".T_ORDER_ITEM_0 (
	ORDER_ITEM_ID BIGINT NOT NULL AUTO_INCREMENT,
	ORDER_ID BIGINT NOT NULL,
	ITEM_NAME VARCHAR(100) NULL,
	ITEM_DESC VARCHAR(100) NULL,
	USER_ID BIGINT NOT NULL,
	CONSTRAINT T_ORDER_ITEM_0_PK PRIMARY KEY (ORDER_ITEM_ID)
);

CREATE TABLE "demo_ds_1".T_ORDER_ITEM_1 (
	ORDER_ITEM_ID BIGINT NOT NULL AUTO_INCREMENT,
	ORDER_ID BIGINT NOT NULL,
	ITEM_NAME VARCHAR(100) NULL,
	ITEM_DESC VARCHAR(100) NULL,
	USER_ID BIGINT NOT NULL,
	CONSTRAINT T_ORDER_ITEM_1_PK PRIMARY KEY (ORDER_ITEM_ID)
);

将达梦数据库驱动包放入 ext-lib 目录下

修改 global.yaml 配置文件

mode:
  type: Standalone
  repository:
    type: JDBC
    
authority:
  users:
    - user: SYSDBA
      password: SYSDBA001
  privilege:
    type: ALL_PERMITTED

复制 database-sharding_db.yaml文件并重命名为database-sharding_dameng.yaml配置文件， 修改此配置文件，仅修改数据库名称和两个数据库源的连接地址

databaseName: sharding_dameng

dataSources:
  ds_0:
    url: jdbc:dm://wsl:30236/demo_ds_0
    username: dhdata   # 客户端登录账号使用此账户登录
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
    minPoolSize: 1
  ds_1:
    url: jdbc:dm://wsl:30236/demo_ds_1
    username: dhdata
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
    minPoolSize: 1

启动 ShardingSphere-Proxy

/ops/app/sharding-proxy/bin/start.sh

报错信息如下

查询了官网，ShardingSphere-Proxy 仅支持 PgSQL 和 MySQL

参考

---

ShardingSphere官方文档

产品手册 | 达梦技术文档

Sharding-JDBC框架 | 达梦技术文档