Apache ShardingSphere

ShardingSphere 是目前 MySQL 分库分表领域最主流的开源中间件之一。它的定位不是简单的“数据库代理”，而是一个分布式数据库生态平台（Distributed Database Ecosystem），用于解决关系型数据库在大规模业务场景下面临的：

数据量过大
单库写入压力过高
数据水平扩展困难
分布式事务复杂
数据治理困难

等问题。

它最初叫 Sharding-JDBC，后来发展成为：

ShardingSphere-JDBC
ShardingSphere-Proxy
ShardingSphere-Sidecar（目前较少使用）

三个主要产品形态。

1. ShardingSphere 的整体架构

先看整体位置。

                 应用程序

                    |
                    |

          ShardingSphere

                    |

        -----------------------

        |          |          |

     MySQL0     MySQL1     MySQL2

     user表     user表     user表

应用认为：

SELECT *
FROM user
WHERE user_id=10001;

实际上：

ShardingSphere

       |
       |
分析SQL

       |
       |
计算分片规则

       |
       |

发送：

mysql1:

SELECT *
FROM user_001
WHERE user_id=10001;

也就是说：

ShardingSphere 把多个物理数据库包装成一个逻辑数据库。

2. ShardingSphere 的三个核心组件

3. ShardingSphere-JDBC

这是目前生产中使用最多的模式。

架构：

        Java应用

            |

       JDBC Driver

            |

    ShardingSphere-JDBC

            |

 --------------------------

 |            |            |

mysql0      mysql1       mysql2

注意：

它不是一个独立服务。

它是：

嵌入应用内部的 Java 数据库访问增强层。

例如：

原来：

DriverManager.getConnection(
"jdbc:mysql://mysql01/test"
)

现在：

jdbc:shardingsphere://cluster

应用连接的是 ShardingSphere。

4. 优点

性能高。

原因：

没有网络代理。

原来：

应用
 |
 |
MySQL

现在：

应用
 |
 |
ShardingSphere代码
 |
 |
MySQL

少了一跳。

5. 缺点

强绑定 Java。

如果你的业务：

Python

Node.js

就不能直接使用。

6. ShardingSphere-Proxy

这是数据库代理模式。

架构：

              应用

               |

          MySQL协议

               |

        ShardingSphere Proxy

               |

 --------------------------------

 |              |               |

mysql0       mysql1          mysql2

应用认为：

连接：

10.0.0.10:3307

其实：

ShardingSphere Proxy

收到 SQL。

例如：

客户端：

SELECT *
FROM orders
WHERE user_id=10;

Proxy：

解析：

user_id=10

10 % 4 = 2

转发：

mysql2

7. 优点

语言无关。

支持：

Java
Python
Go
PHP

因为：

所有语言都会 MySQL 协议。

8. 缺点

多一次网络。

链路：

client

 |

Proxy

 |

MySQL

性能稍低。

9. Sidecar

类似 Kubernetes Sidecar。

例如：

Pod

-----------------

业务容器

ShardingSphere Sidecar


-----------------

MySQL

目前应用较少。

10. ShardingSphere 内部核心流程

这是最重要部分。

一次 SQL：

select *
from orders
where user_id=100;

经历：

SQL

 |

SQL Parser

 |

SQL Router

 |

SQL Rewrite

 |

SQL Executor

 |

Result Merger

下面逐个介绍。

11. SQL Parser（SQL解析）

作用：

把 SQL 从字符串变成结构化对象。

例如：

SQL：

SELECT *
FROM orders
WHERE user_id=100

解析后：

类似：

SQLStatement

{
 table:
    orders

 condition:
    user_id=100
}

为什么需要解析？

因为它需要知道：

查询哪个表
条件是什么
是否包含分片字段
是否需要改写

例如：

SQL：

select *
from orders
where id=10

解析：

table:

orders


condition:

id=10

12. SQL Router（路由引擎）

这是分片核心。

输入：

逻辑表:

orders


分片条件:

user_id=100

规则：

database = user_id % 4

table = user_id % 8

计算：

100 % 4 =0

100 %8 =4

得到：

数据库:

db0


表:

orders_4

最终：

db0.orders_4

13. 路由类型

ShardingSphere支持：

14. 精确路由

例如：

where user_id=100

结果：

一个库

一个表

最快。

15. 范围路由

例如：

where user_id >100

不知道具体位置。

可能：

db0

db1

db2

db3

全部查询。

16. 广播路由

例如：

查询：

所有库中的配置表

发送：

所有节点

17. SQL Rewrite（SQL改写）

路由结束后：

需要把逻辑SQL变成真实SQL。

例如：

用户写：

SELECT *
FROM orders
WHERE user_id=100;

实际：

db0

orders_4

改写：

SELECT *
FROM orders_4
WHERE user_id=100;

18. SQL Executor（执行引擎）

如果：

一个目标：

db0.orders_1

直接执行。

但是：

如果：

select *
from orders

没有分片条件。

可能：

生成：

SQL0:

db0.orders


SQL1:

db1.orders


SQL2:

db2.orders

执行模式：

19. 内存限制模式

一个一个执行：

db0

完成

db1

完成

节省资源。

20. 连接限制模式

并发：

db0 线程1

db1 线程2

db2 线程3

速度快。

但是：

连接压力大。

21. Result Merger（结果合并）

例如：

三个数据库：

db0:

id
1
5

db1:

id
2
8

db2:

id
3
9

用户：

ORDER BY id

ShardingSphere需要：

排序：

这个过程：

叫：

结果归并

22. 分片规则配置

例如：

4个数据库：

ds0

ds1

ds2

ds3

表：

orders_0

orders_1

orders_2

orders_3

配置：

rules:

sharding:

tables:

 orders:

  actualDataNodes:
    ds${0..3}.orders_${0..3}


 databaseStrategy:

  standard:

    shardingColumn:
       user_id

    algorithm:
       inline

规则：

ds${user_id % 4}

23. 分布式事务

ShardingSphere支持：

24. XA模式

基于：

Atomikos
Narayana

特点：

强一致。

但是：

性能低。

25. BASE模式

最终一致。

例如：

订单：

order_db

支付：

payment_db

通过：

消息队列

同步。

互联网更常用。

26. ShardingSphere 和 MySQL 主从结合

生产一般：

不是：

ShardingSphere

 |

MySQL

而是：

                 ShardingSphere


                      |


 ------------------------------------------------

 |                    |                         |

订单分片0          订单分片1                 订单分片2


master             master                   master


 |                  |                         |

slave              slave                    slave

然后：

写：

master

读：

slave

实现：

分片解决容量

+
主从解决读压力

27. ShardingSphere 生产故障分析

28. 故障1：分片键热点

现象：

db2 CPU 100%

其他数据库30%

原因：

user_id

分布不均

解决：

更换分片键
增加二级hash
热点隔离

29. 故障2：慢SQL导致全库扫描

SQL：

select *
from orders
where create_time>'2026-01-01'

没有：

user_id

结果：

16个库全部查询

CPU暴涨。

解决：

增加：

时间分区表

ES同步查询

冷热分离

30. 故障3：扩容迁移

原：

4库

扩：

8库

问题：

大量数据迁移。

期间：

旧数据

+

新写入

需要：

双写：

old

new

或者：

数据同步。

31. 从云数据库运维角度应该关注什么？

如果你以后做腾讯云数据库类似平台，ShardingSphere只是其中一层。

更重要的是：

32. 数据面

MySQL：

CPU

IOPS

Buffer Pool

Redo Log

Binlog

Lock

33. 分片面

Shard数量

Shard数据量

Shard QPS

Shard延迟

热点Shard

34. 调度面

实例创建

迁移

扩容

缩容

故障恢复

35. AI方向

可以做：

指标采集

    |

异常检测模型

    |

预测Shard热点

    |

自动迁移

结合你的方向（云运维 + Kubernetes + Prometheus + AIOps），ShardingSphere 最值得深入的不是 API 使用，而是它背后的分布式数据库治理思想：

逻辑资源抽象 → 路由调度 → 数据分布 → 负载均衡 → 自动治理

这个思想和 Kubernetes Scheduler、Volcano 调度器其实非常相似。

下一步建议学习 “ShardingSphere 源码架构：SQL解析器、路由引擎、执行引擎源码流程”，因为它和你正在学习的 K8s Controller / Scheduler 设计思想高度类似。

关联文档

MySQL 基础：MySQL 数据库基础与运维入口。

YancheBlog

热门标签

Apache ShardingSphere

Apache ShardingSphere

1. ShardingSphere 的整体架构

2. ShardingSphere 的三个核心组件

3. ShardingSphere-JDBC

4. 优点

5. 缺点

6. ShardingSphere-Proxy

7. 优点

8. 缺点

9. Sidecar

10. ShardingSphere 内部核心流程

11. SQL Parser（SQL解析）

12. SQL Router（路由引擎）

13. 路由类型

14. 精确路由

15. 范围路由

16. 广播路由

17. SQL Rewrite（SQL改写）

18. SQL Executor（执行引擎）

19. 内存限制模式

20. 连接限制模式

21. Result Merger（结果合并）

22. 分片规则配置

23. 分布式事务

24. XA模式

25. BASE模式

26. ShardingSphere 和 MySQL 主从结合

27. ShardingSphere 生产故障分析

28. 故障1：分片键热点

29. 故障2：慢SQL导致全库扫描

30. 故障3：扩容迁移

31. 从云数据库运维角度应该关注什么？

32. 数据面

33. 分片面

34. 调度面

35. AI方向

目录