关于数据库:ShardingSphere-4x-数据分片使用规范之SQL

背景

尽管 ShardingSphere 心愿可能齐全兼容所有的 SQL 以及单机数据库，但分布式为数据库带来了更加简单的场景。ShardingSphere 心愿可能优先解决海量数据 OLTP 的问题，OLAP 的相干反对，会一点一点的逐步欠缺。

请进一步浏览 ShardingSphere 所反对和不反对的 SQL 类型以及针对分页这类性能相关度很高的问题。

因为 SQL 语法灵便简单，分布式数据库和单机数据库的查问场景又不完全相同，不免有和单机数据库不兼容的 SQL 呈现。

本文具体列举出已明确可反对的 SQL 品种以及已明确不反对的 SQL 品种，尽量让使用者防止踩坑。

其中必然有未波及到的 SQL 欢送补充，未反对的 SQL 也尽量会在将来的版本中反对。

反对项

路由至单数据节点

• 100% 全兼容（目前仅 MySQL，其余数据库欠缺中）。

路由至少数据节点

全面反对 DML、DDL、DCL、TCL 和局部 DAL。反对分页、去重、排序、分组、聚合、关联查问（不反对跨库关联）。以下用最为简单的 DML 举例：

• SELECT 主语句

SELECT select_expr [, select_expr ...] FROM table_reference [, table_reference ...]
[WHERE predicates]
[GROUP BY {col_name | position} [ASC | DESC], ...]
[ORDER BY {col_name | position} [ASC | DESC], ...]
[LIMIT {[offset,] row_count | row_count OFFSET offset}]

• select_expr

* | 
[DISTINCT] COLUMN_NAME [AS] [alias] | 
(MAX | MIN | SUM | AVG)(COLUMN_NAME | alias) [AS] [alias] | 
COUNT(* | COLUMN_NAME | alias) [AS] [alias]

• table_reference

tbl_name [AS] alias] [index_hint_list]
| table_reference ([INNER] | {LEFT|RIGHT} [OUTER]) JOIN table_factor [JOIN ON conditional_expr | USING (column_list)]

不反对项

路由至少数据节点

不反对 CASE WHEN、HAVING、UNION (ALL)，无限反对子查问。

除了分页子查问的反对之外(详情请参考分页)，也反对等同模式的子查问。无论嵌套多少层，ShardingSphere 都能够解析至第一个蕴含数据表的子查问，一旦在上层嵌套中再次找到蕴含数据表的子查问将间接抛出解析异样。

例如，以下子查问能够反对：

SELECT COUNT(*) FROM (SELECT * FROM t_order o)

以下子查问不反对：

SELECT COUNT(*) FROM (SELECT * FROM t_order o WHERE o.id IN (SELECT id FROM t_order WHERE status = ?))

简略来说，通过子查问进行非性能需要，在大部分状况下是能够反对的。比方分页、统计总数等；而通过子查问实现业务查问以后并不能反对。

因为归并的限度，子查问中蕴含聚合函数目前无奈反对。

不反对蕴含 schema 的 SQL。因为 ShardingSphere 的理念是像应用一个数据源一样应用多数据源，因而对 SQL 的拜访都是在同一个逻辑 schema 之上。

对分片键进行操作

运算表达式和函数中的分片键会导致全路由。

假如 create_time 为分片键，则无奈准确路由形如 SQL：

SELECT * FROM t_order WHERE to_date(create_time, 'yyyy-mm-dd') = '2019-01-01';

因为 ShardingSphere 只能通过 SQL字面 提取用于分片的值，因而当分片键处于运算表达式或函数中时，ShardingSphere 无奈提前获取分片键位于数据库中的值，从而无奈计算出真正的分片值。

当呈现此类分片键处于运算表达式或函数中的 SQL 时，ShardingSphere 将采纳全路由的模式获取后果。

示例

反对的 SQL

不反对的 SQL

DISTINCT 反对状况具体阐明

反对的 SQL

不反对的 SQL