接下来我们针对DAS的SQL诊断优化服务能力构建进行详细的解读。
在SQL诊断优化领域,基于规则方式和基于代价模型方式是两种常被选择的优化推荐算法,在目前许多产品和服务中,基于规则的推荐方式被广泛使用,特别是针对MySQL这种WHAT-IF内核能力缺失的数据库,因为该方式相对来说比较简单,容易实现,但另一面也造成了推荐过于机械化,推荐质量难以保证的问题, 举一个例子,例如对如下简单的SQL进行索引的推荐:
SELECT *
FROM t1
WHERE time_created >= '2017-11-25'
AND consuming_time > 1000
ORDER BY consuming_time DESC
IX1(time_created)
IX2(time_created, consuming_time)
IX3(consuming_time)
IX4(consuming_time, time_created)
但最终推荐给用户的是哪个(或哪几个,考虑index oring/anding的情况)索引呢?基于规则的方式很难给出精确的回答,会出现模棱两可的局面。在这个例子中,SQL只是简单的单表查询,那对于再复杂一点的SQL, 例如多个表Join,以及带有复杂的子查询,情况又会如何呢?情况变得更糟糕,更加难以为继。
-
WHAT-IF内核能力缺失:无法复用内核的数据库优化器能力来对候选优化方案进行代价量化评估; -
统计信息缺失:候选优化方案的代价评估,其本质是执行计划的代价计算,统计信息的缺失便是无米之炊。
-
足够完备性保证:影响SQL优化的因素很多, 例如影响索引选择的因素有上百个,加之各因素之间形成组合,这就形成了庞大的案例特征集合,如何让这些特征一一映射到测试案例也是非常庞大的工程; -
测试案例设计需要专业知识且信息量大,例如对于单一测试案例设计也需要专业知识且测试案例中携带的信息量大,如索引推荐测试案例,它包括:
SQL诊断优化服务需要具备服务于云上百万级数据库实例的能力,其线上服务能力同样面临巨大挑战,例如如何实现复杂的计算服务服务化拆分,计算服务的横向伸缩,最大化的并行,资源访问分布式环境下的并发控制,不同优先级的有效调度消除隔离,峰值缓冲等等。
能力构建
面对上面提到的众多挑战,下面着重从DAS中的SQL诊断优化引擎核心技术架构以及能力测试集的构建两个维度进一步解读。

-
SQL解析与验证:引擎对查询语句做解析验证,验证输入查询语句是否符合标准,识别查询语句的组成形成语法树,例如:谓词以及谓词类型、排序字段、聚合字段、查询字段等,识别查询语句相关字段的数据类型。验证SQL使用到的表、字段是否符合目标数据库的结构设计。 -
候选索引生成:依据解析验证后的语法树,生成多种候选索引组合; -
基于代价评估:代价评估基于内置独立于数据库内核的优化器,获取数据库统计信息,在诊断引擎内部作缓存。诊断引擎内置优化器基于统计信息计算代价,评估每个索引的代价以及不同SQL改写方法下的代价评估,从而从代价选择最优索引或SQL改写方法。 -
索引合并与择优:引擎输入可以是一条查询语句,也可以为多个查询语句,或者整个数据库实例所有的查询语句。为多个查询语句做索引推荐,不同的查询语句的索引建议,以及已经存在的物理索引,有可能存在相同索引、前缀相同索引、雷同索引。

4)各能力级的测试用例覆盖率怎样?
-
自助优化:集团用户指定问题SQL, 服务完成诊断并提供优化专家建议; -
自动优化:自动优化服务自动识别业务数据库实例工作负载上的慢查询,主动完成诊断,生成优化建议,评估后编排优化任务,自动完成后续的优化上线操作及性能跟踪,形成全自动的优化闭环,提升数据库性能,持续保持数据库实例运行在最佳优化状态。
更为重要的是,SQL诊断优化服务已经构建了有效的主动式分析,反馈系统,线上诊断失败案例,用户反馈案例,自动优化中的回滚案例会自动回流到案例系统,一刻不停地驱动着诊断服务在快速迭代中成长。
提示:
DAS 支持MySQL、PG、MongoDB、Redis、PolarDB;
环境支持
环境 | 统一接入 | 统一监控 | 统一告警 | 统一Dashboard |
---|---|---|---|---|
阿里云公共云RDS | 支持 | 支持 | 支持 | 支持 |
阿里云公共云ECS自建数据库 | 支持 | 支持 | 支持 | 支持 |
用户自建IDC MySQL | 支持 | 支持 | 支持 | 支持 |
用户自建IDC Redis | 支持 | 支持 | 支持 | 支持 |
定价
定价 | 超出部分说明 |
---|---|
40元/实例/月 | 套餐中会赠送5GB SQL洞察存储空间(限中国内地Region),超过部分按照0.008/GB/小时收费。 |
购买咨询及优惠请联系科劳得。