一、ShardingSphere 分片使用规范

1.1 支持项

路由至单数据节点

ShardingSphere 目前对 MySQL 数据库实现 100% 全兼容。

路由至多数据节点

SQL 支持范围：

类型说明
DQL（数据查询语言）支持 SELECT 查询
DML（数据操作语言）支持 INSERT、UPDATE、DELETE
DDL（数据定义语言）支持 CREATE、ALTER、DROP
DCL（数据控制语言）支持 GRANT、REVOKE
TCL（事务控制语言）支持 COMMIT、ROLLBACK

高级查询功能：

  • 分页、去重、排序、分组与聚合
  • 关联查询（仅限同一数据库实例内，不支持跨库关联）

1.2 不支持项

路由到多数据节点

  • 所有查询只能在单个数据节点上执行
  • 跨节点的数据关联操作需要通过应用层自行实现

SQL 语法限制

  1. CASE WITH 语法：不支持在 CASE 表达式中嵌套 WITH 子句
  2. HAVING 子句：分组后的过滤条件无法直接使用
  3. UNION/UNION ALL 操作：无法合并多个查询结果集

1.3 分页子查询限制

支持的分页子查询类型：

  • 单层嵌套的分页子查询

不支持的子查询类型：

  • 多层嵌套子查询
  • 包含业务逻辑的子查询

1.4 聚合查询

由于归并的限制，子查询中包含聚合函数目前是无法支持的。

1.5 Schema

不支持包含 Schema 的 SQL，ShardingSphere 的设计理念是让用户像使用单一数据源一样使用多个数据源。

二、分片键的运算表达式处理机制

2.1 路由原理

当 SQL 查询的分片键处于运算表达式或函数中时，ShardingSphere 会采用全路由方式执行查询。

2.2 典型场景示例

日期函数处理场景

SELECT * FROM b_order
WHERE to_date(create_time, 'yyyy-MM-dd') = '2025-06-25';

数学运算场景

SELECT * FROM user_transaction
WHERE user_id % 10 = 5;

2.3 优化建议

为避免全表扫描带来的性能问题，建议：

  1. 将运算逻辑前置到应用层
  2. 使用明确的分片键值进行查询

三、分页查询优化方案详解

3.1 大偏移量性能问题分析

当查询偏移量过大时，会引发以下性能瓶颈：

  • 数据库需要扫描并跳过大量记录
  • 客户端需要处理大量记录的归并排序
  • 网络传输量呈指数级增长

3.2 ShardingSphere 的优化方案

  • 流式批处理：采用分批次获取数据的方式
  • 归并排序优化：使用堆排序算法进行多路归并

3.3 分页替代方案

ID 连续分页法

SELECT * FROM b_order
WHERE id > 1000000 AND id <= 1000010
ORDER BY id;

游标分页法

SELECT * FROM b_order
WHERE id > 100000
ORDER BY id
LIMIT 10;

3.4 最佳实践

  1. 避免使用 LIMIT N,M 式分页
  2. 分页查询必须配合 ORDER BY 使用
  3. 推荐每页数据量控制在 100 条以内
  4. 对于深度分页，强制要求使用游标分页