状态：原创
大家好，我是 Raigor，Apache ShardingSphere Committer，同时也算是 ShardingSphere 的资深用户。
从 3.1.0 开始，我负责的业务系统就接入了 ShardingSphere-JDBC 和 ShardingSphere-Proxy，形成了如下的混合架构：
其中 Web 端应用接入 ShardingSphere-JDBC，与接入 Proxy 相比，ShardingSphere-JDBC 减少了网络层的调用，SQL 执行性能更高。
另一方面，部署一个 ShardingSphere-Proxy 服务，使用与 ShardingSphere-JDBC 完全一致的数据源和分片规则（YAML 配置）。这样，开发和运维人员就可以通过 Navicat、DBeaver 这样的客户端连接到 Proxy，方便查询和管理分片后的大量数据。
不过，在使用过程中依然是有一些不便的：
- 若要新增一个 sharding table rule，JDBC 端需要修改配置文件，Proxy 端也需要同步修改；
- 修改配置不能实时生效，须择机重启系统；
- 随着分片规则的增多，配置文件越来越长，维护复杂度也在增加；
- 部署了多个应用和 Proxy，配置文件有多份，手工维护可能导致各个文件内容顺序不一致；
- 应用和配置文件部署在云服务器上，改远端文件比本地文件总要麻烦一点；
- 开发者一边通过 Navicat 管理数据，一边通过 SSH 调整配置，要在多个工具间来回切换；
- 等等。。。
当然，在接入 Apache ShardingSphere 进行数据分片后，整个应用系统的性能得到巨幅提升，之前提到的不便也不是大问题了，「理解万岁！」。
时间来到 2021 年 11 月，Apache ShardingSphere 5.0.0 GA 版本正式发布，DistSQL 就是 5.0.0 中的一个重磅特性。
有了 DistSQL，用户可以从繁杂的 YAML 配置文件中解脱出来，现在：
-
若要新增一个 sharding table rule：执行
CREATE SHARDING TABLE RULE语句，JDBC 端和 Proxy 端同步； -
修改配置实时生效，无需重启；
-
分片规则增多没关系，SHOW 语句精确过滤：
SHOW SHARDING TABLE RULE t_order -
多个应用和 Proxy 共用配置中心，配置仅需维护一份；
-
没有修改远端配置文件的烦恼了；
-
一个 SQL 客户端（如 Navicat） 搞定数据管理和配置管理，不用切换客户端；
看，之前的不便全都消失了，这体验：
值得注意的是，要实现以上效果，原来的系统架构只需要增加一个注册中心，让 ShardingSphere-JDBC 和 ShardingSphere-Proxy 两端同时接入同一个注册中心上：
配置注册中心的方式也很简单，像这样：
mode:
type: Cluster
repository:
type: ZooKeeper
props:
namespace: governance_ds
server-lists: localhost:2181
retryIntervalMilliseconds: 500
timeToLiveSeconds: 60
maxRetries: 3
operationTimeoutMilliseconds: 500
overwrite: false
以上配置的说明可参考 文档
就这样，通过 DistSQL，开发和运维的体验得到了极大的提升，那有没有什么限制呢？
很遗憾，目前还有一点：DistSQL 只能通过 Proxy 执行，即如果 ShardingSphere-JDBC 的用户想要动态修改配置，需要通过注册中心接入一个 Proxy 来实现需求。
当然，Apache ShardingSphere 提供了一个开放的、快速发展的社区，未来更多的精彩，让我们携手前行，拭目以待。
参考资料：
关于 DistSQL 更详细的操作演示，可阅读: DistSQL：像数据库一样使用 Apache ShardingSphere
由于版本迭代，若发现个别语句不能使用，还请对照 官方文档。
