表格存储（Tablestore）是阿里云自研的多模型结构化数据存储，提供海量结构化数据存储以及快速的查询和分析服务。表格存储的分布式存储和强大的索引引擎能够支持 PB 级存储、千万 TPS 以及毫秒级延迟的服务能力。使用表格存储你可以方便的存储和查询你的海量数据。

表格存储在 21 年 9 月正式公测了 SQL 功能，使得你在享受表格存储全托管，灵活的存储能力之外，可以让你的业务迁移更加平顺。经过几个月的公测和反馈，我们今天正式发布表格存储 SQL 商业化版本，基于这个版本，您可以放心的进行生产业务的迁移。目前我们提供控制台，官方 cli，官方 Java SDK 和 Go SDK，以及表格存储的 JDBC Driver，Go database driver 等多种方式进行 SQL 的访问。 具体可以参考我们的官方文档。
本文主要介绍下表格存储 SQL 功能的使用场景和功能，基本概念和 SQL 使用最佳实践。
具体计费详细介绍可以参考SQL查询计量计费。

使用场景

表格存储 SQL 和之前的产品功能一致，是全托管免运维的，当使用 SQL 访问表格存储和 SDK 直接读取数据在费用上一致，不会额外收费。这样在可以享受访问接口的便利性和计算能力同时，对于一些之前需要拉取较多数据二次计算的场景可以大幅减少客户端的数据传输，提升访问性能。那我们这里我们简单总结下表格存储 SQL 适合的场景。

基础数据查询

GetRow / GetRange 的替换。如果您的场景是大量是用表格存储进行基于主键的点查，范围查询。那么你可以很方便的替换成 SQL 的查询，同时我们可以实现线上几万每秒到几十万每秒的高并发访问能力。

基于多元索引的检索与统计聚合

使用多元索引的各类多字段检索，统计聚合能力等。如果您的场景是使用多元索引，进行多字段组合查询，又或者是全文检索，统计聚合查询等，这些您可以不再需要理解 SDK 的写法，直接使用 SQL 来进行数据链路的访问。相信在查询相对复杂的情况下，SQL 可以更方便您进行查询语义的表达。

主表与索引组合查询

主表，索引的组合查询使用。我们提供自动索引选择能力，可以在您查询时，根据查询条件预估查询开销，进行智能的索引选择。

轻量级统计聚合

轻量级的聚合分析，对于主表和全局二级索引，我们支持基于索引命中后进行扫描 10w 条记录的实时在线聚合计算（如有更大规模计算可以联系我们调整）。对于能命中多元索引查询，我们会利用索引引擎的计算能力不限制单次计算数据量。

时序模型的查询和分析

时序模型的各类查询场景，表格存储推出了针对时序场景的定制化存储引擎和分析能力。您也可以使用同样的访问入口，针对时序模型的数据进行各类查询，这里我们会提供一些针对时序场景的定制算子支持。
对于目前具体支持的 SQL 语法列表可以在我们的官方文档中查看。
如果您的场景没在上述列表中，您也希望通过 SQL 来进行访问，您可以通过工单或者钉钉群找到我们进行反馈，我们的 SQL 功能在快速迭代，会有更多更强大的能力持续发布。

基本概念

表格存储是一个 Schema free 的结构化存储产品，所以在您使用之际，只需要定义主键，不需要定义完整行的结构。但是在 SQL 查询中，通常是需要有 Schema 概念的，便于做数据类的的检查，投影，计算等操作。所以我们定义了 SQL 绑定概念。即在第一次使用SQL的时候，对一张表，需要通过 Create Table 语句进行表 Schema 定义。这个语句和普通的创建表没有区别，但是对于已经在 OTS 的表，他不会重新创建数据表，是进行一个 Schema 定义并在SQL 中关联。关联后即可以对已有的表格存储表开启 SQL 查询。
表格存储之前使用实例，表和索引这些概念表示对应的资源，对应在 SQL 中我们也有标准的映射，具体如下：

进行建表（前置条件表格存储中该表已经存在，通过 SQL 语法定义 Schema）：

建表语法

CREATE TABLE [IF NOT EXISTS] table_name(column_name data_type [NOT NULL | NULL],...
| PRIMARY KEY(key_part[,key_part]));

建表样例

CREATE TABLE exampletable1 (id BIGINTPRIMARY KEY, colvalue BIGINT, content MEDIUMTEXT);

你可以通过控制台页面，或者 SDK 执行这条 SQL 语句。其中如果您使用了控制台，控制台可以根据表中已有数据做一些探测，自动帮助您生成建表语句。如下图所示点击确认后，探测出的 Schema 我们会自动产出一条 SQL 语句。

在创建了绑定表以后，就可以像查询 MySQL 一样进行数据查询了。

最佳实践

同样的查询需求，不同的 SQL 写法或者存储引擎也会产生很大的性能差别。您可以参考我们的 "索引选择策略" 和 "计算下推"。更优的索引选择会减少单次扫描的数据量，提升性能，计算下推会把可能的算子推到存储层，减少存储层和计算引擎之间的数据交互，这两部分的能力都可以大幅降低整体的访问延时。这里我们举两个例子做为说明：

场景1 基于索引进行多字段组合查询

假设我们有一张订单表，表中会存储订单的明细各类字段。其中在表格存储中的主键定义如下（备注：场景中的案例使用测试数据，非生产样例）：

在表格存储中的数据样例如下：

针对这张表，如果我们基于主键查询，可以很快获取结果例如

SELECT * FROM `ordertable` where `order` = "xxx"

这是因为这样的一个查询条件会被利用主键索引，变成一个小范围的 range 查询，如果你指定了全部主键就会自然的变成点查询。
那如果我们希望通过属性列来查询数据性能会怎么样呢？熟悉存储原理的同学不难理解，如果没有其他额外索引，我们需要通过属性列进行过滤，那往往可能会触发整表的数据扫描再返回最终结果。这时候性能可能会大不及预期。如果我们创建了一个多元索引，包含您要查询的所有字段。性能会非常的快：

这是因为，我们 SQL 会根据您的索引情况，进行动态选择，把 SQL 查询转化成对应的 Search 查询，利用倒排索引的特性，快速执行整条 SQL 语句。

场景2 计算下推

我们继续使用这张订单表，假设我们的查询除了过滤还有一些统计聚合。在没有多元索引的情况下，SQL 会先根据 Filter 捞取命中的数据，然后在执行统计聚合。有多元索引的情况下，SQL 会利用 Search 支持轻量级聚合的能力。例如如下 SQL 场景，我们希望按照用户维度查看购买 top 20 的订单金额信息。

SELECT sum(productprice) as total, customerid FROM `ordertable` group by customerid order by total desc LIMIT 20;

在没有多元索引的场景下，如果您的订单总量很大，会触发到我们的扫描上限（有放大需求可以加钉钉群或者工单咨询）。同时也会导致性能较差，如果使用了多元索引，就可以在秒级别进行这样的聚合查询。

最后对于 SQL 的使用性能问题，索引如何优化问题，欢迎加入我们的交流群讨论。

总结

更详细的功能介绍，欢迎参考表格存储官网文档，可以查看具体的 SQL 语法，用例，限制项等。
想了解更多表格存储的用法或者咨询欢迎加群讨论：
我们的开发者技术交流群，可搜索群号『11789671』或『23307953』，亦可直接扫码加入。