共计 3139 个字符，预计需要花费 8 分钟才能阅读完成。
简介：DAS 推出了全局 Workload 优化性能，能够及时检测到数据库的负载变动，辨认到新增 SQL、执行变动的 SQL 以及性能不佳的 SQL，并综合思考 SQL 的执行频率和相干 SQL 信息，给出优化倡议。
背景
日常的数据库优化中，在数据库的表上创立适合的索引是解决慢 SQL 查问问题的一种十分重要且罕用的计划。在处理过程中，DBA 或者开发人员通常会依据实例上的慢 SQL 信息进行优化，DAS 主动 SQL 优化性能曾经实现了依据慢 SQL 进行主动诊断，并创立适合的索引。但该计划会面临如下几个挑战：
- 数据采集问题：一些业务 SQL 并没有达到慢 SQL 采集的阈值（比方 1s），而这些 SQL 查问自身没有很好的利用索引，查问效率不高，依然有很大的优化空间。在并发量增大或者表数据增多的状况下，这些查问很容易造成实例性能忽然好转而引起故障。
- 写入代价问题：在创立索引时通常更重视进步数据读取的效率，而疏忽索引保护对写入性能的影响和空间占用的老本，对于写多读少的表，创立太多索引反而会影响零碎吞吐。
- workload 变动问题：索引一旦创立，通常状况下很少变动，而业务却始终在动态变化中。随着业务一直迭代变动，一些索引可能不再有 SQL 应用，或者应用频率很低，此时须要引入更优的索引设计来晋升数据库的解决性能。
为了解决上述问题，DAS 推出了全局 Workload 优化性能，它能够及时检测到数据库的负载变动，辨认到新增 SQL、执行变动的 SQL 以及性能不佳的 SQL，并综合思考 SQL 的执行频率和相干 SQL 信息，给出优化倡议。
解决方案介绍
全局 Workload 优化，次要由三局部组成。
Workload 检测：依据数据库实例上和 Workload 相干的性能指标 (如 RT，CPU 等) 以及全量 SQL 相干指标(执行次数、执行耗时、扫描行数等)，训练数据模型，实时检测 Workload 的 SQL 执行状况，从而辨认新增 SQL、执行变动的 SQL，以及整个负载变动的周期。
如下图所示，全量 SQL 执行情况指标在 period1 和 period2 呈周期性状态，至 period3，执行情况发生变化。全局 Workload 优化，依据数据训练模型，轻松实现辨认负载变动的工夫区间。
全局诊断：全局诊断优化则依据数据库在某一时间范畴内的全副 SQL 执行状况，综合思考 SQL 的查问和写入性能以及空间占用状况，举荐最优索引组合，从而从 SQL 角度最大限度进步数据库的性能，升高数据库导致的问题的概率。
智能压测：智能压测能够回放实例上某个时间段内的全副 SQL（该性能会在相干文章中具体解读），将全局诊断和智能压测联合后，零碎能够在测试实例上依据诊断倡议主动创立索引，回放历史流量并比照驳回倡议前后的 SQL 执行状况，生成测试报告。
具体实现
触发机会
全局 workload 诊断反对用户自定义触发和零碎自动检测触发两种模式：用户触发能够依据业务需要制订工夫区间，触发全局诊断获取优化倡议；自动检测会实时监测实例的负载信息，检测到数据库有异样 SQL 呈现，或者发现 Workload 整体趋势变动，及时触发全局 workload 诊断。其中异样 SQL 包含：(1) 新增 SQL；(2) 执行次数占比浮动 20% 以上 SQL；(3) 执行均匀 RT 浮动 20% 以上 SQL 等。
通过自动检测机制，能够帮忙用户及时发现结构设计落后于业务变动的场景，缩小故障产生的概率以及资源节约。
数据起源
全局 workload 诊断的数据起源是 SQL 审计，包含 SQL 类型、SQL 模版、执行次数以及 SQL 性能信息等。SQL 审计会记录诊断工夫内执行的所有 SQL，因而能够发现不是慢 SQL 但性能欠佳的 SQL 问题。
关联 SQL 剖析
通过解析 SQL 模版和元数据，能够剖析出 SQL、表、列之间的拜访关系，从而失去可能相互影响的 SQL 汇合。通过关联性剖析，能够无效地缩小后续求解问题的复杂度，同时为索引上线后的性能跟踪服务提供根底的数据反对。
候选索引生成及代价评估
该模块和前面的优化求解是全局 workload 优化的外围模块。在单 SQL 的索引举荐中能够依据一些规定或者教训来举荐索引，也能获得肯定的成果，但基于全局 workload 的优化基于规定的办法就简直有效了，必须可能将代价进行量化。咱们基于 DAS 实现的外置优化器，能够做到疾速精确的解析语法树、采样收集统计信息、生成候选索引以及计算应用某个索引的代价。
优化求解
在确定候选索引集以及索引代价的状况下，抉择最有索引汇合的过程能够等价为一个背包问题的变种。抉择某个索引的收益等价为放入背包物品的价值，因为创立一个索引既能够给查问带来正收益也会对写入和空间老本带来副收益，因而价值能够是负数也能够是正数。背包的容量是一个表上最多建设索引的阈值（用户设置或零碎默认，并非数据库存储束缚）。咱们的指标是使得背包中物品价值最大。另外须要留神的是，当抉择一个索引后，它会对其余索引的价值产生影响，因而在每次迭代抉择物品时须要依据曾经存在索引的状况，更新残余待选索引的价值。
索引 I 代价 = 执行次数 *（a* 读收益 – b* 写代价 – c* 空间占用）
成果验证
为了保障优化倡议的有效性，咱们和智能压测性能整合到一起，提供疾速不便的验证计划。智能压测系统会主动搭建测试实例上并同步实在数据，而后在测试上主动驳回优化倡议，回放诊断时间段内的全量 SQL 并采集 SQL 执行的性能数据，最初比照生成测试报告。这种计划的益处是既保证了测试场景和线上业务的一致性，又不会对线上运行业务造成影响，同时还能预估驳回倡议后产生的影响。
示例
比方表 1 中存在 6 条 SQL，如果独立的看每一条 SQL，失去的优化索引可能为表 2 中的 4 条索引；而从 workload 维度来看，索引能够合并为表 3 的两条索引。两种后果比照，整体 RT 降落 14.45%，索引空间节俭 50%。
SQL2：idx\_is\_deleted\_gmt\_modified (is\_deleted, gmt\_modified)
SQL4 : idx\_name(name)
SQL5: idx\_name\_id\_birth\_date (name, id, birth\_date)
SQL6: idx\_name\_nick\_name（name, nick\_name）
idx\_is\_deleted\_gmt\_modified (is\_deleted, gmt\_modified)
idx\_name\_id\_birth\_date (name, id, birth\_date)
将来打算
全局 Workload 优化将来会打造主动优化的闭环，包含 workload 异样检测、全局 workload 诊断、智能压测成果评估，主动驳回倡议、成果跟踪及异样解决。另外，目前全局 workload 优化思考了 SQL 执行频率，SQL 查问和写入的影响，但没有思考固定参数或者参数歪斜等问题，前面能够进一步将这些业务属性纳入到思考因素当中。
** 相干浏览：
**
数据库自治服务 DAS 公布年度新版本：1-5000，”数据库主动驾驶“进入规模化时代
深度技术揭秘 | 大促狂欢背地，如何无效评估并布局数据库计算资源？
重磅 | 数据库自治服务 DAS 论文入选寰球顶会 SIGMOD，领航“数据库主动驾驶”新时代
干货|SQL 申请行为辨认新性能上线，帮忙解决异样 SQL 检测之海底捞针问题
干货|一文读懂阿里云数据库 Autoscaling 是如何工作的
版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
