阿里数据库智能优化技术本文介绍基于阿里的场景和规模所做的一些思考和实践。

首先在阿里对数据库优化服务的诉求，大家在数据库性能优化方面都有很多的经验教训，不同公司对优化的具体做法也不太一样。

在方式上，大部分企业应该还是重人工模式，就是由数据库能力比较强的人，比如DBA，来解决数据库性能问题。

但阿里今天的数据库规模非常大，不管我们有多少DBA，我们的人员增长速度都无法跟上业务发展的速度，单纯依赖DBA已经无法满足业务发展需求。

第二方面分析CloudDBA是如何做的，里面涉及到哪些技术，希望把这些技术分享给大家。

如果大家所在的公司也在做类似的事情，希望能够提供一些参考和帮助。

第三方介绍目前正在探索的一些事情。

现在人工智能技术比较火，数据库相对来说是比较传统的领域。

如果我们将机器学习、深度学习这样的技术引入到数据库领域，它到底能做些什么，具体到数据库优化领域又能做什么，这是我们正在探索的一些事情。

一、阿里数据库优化服务诉求1、业务诉求首先从整个阿里数据库的角度看一下对于数据库优化服务的业务诉求，这也是我们做这个产品最大的驱动力。

（1）服务产品化。

阿里业务发展速度远远超过了DBA团队发展的速度，单独依靠DBA重人工支持模式变得越来越困难，因此我们在几年前开始尝试通过产品来完成DBA人工做的一些工作。

通过产品解决DBA人工服务的扩展性问题，是我们最直接的诉求，希望能把DBA人工服务产品化。

（2）全局规模优化。

站在全局角度来看，数据库规模迅速增大的同时也带来了巨大的成本压力。

成本这块怎么理解呢？只要业务有需求，理论上可以通过增加更多的机器来满足业务需求。

但从另外一个角度来讲，这些机器是不是一定要加？是不是有一些机器可以通过优化节省下来给新的业务服务？当规模非常大时，所做的一小点规模化优化，所节省的成本可能都是很可观的。

因此我们需要有全局规模优化的能力，仅仅一个数据库实例内部做的优化都是一些局部优化，以全局角度来看是不够的。

（3）主动诊断。

从运维的角度来看，阿里同其它公司一样，就是要尽量避免故障的发生。

在阿里的业务场景下，大部分业务跟数据库有着非常紧密的关系。

数据库一个微小的抖动，都可能对业务造成非常大的影响，所以如何让数据库更稳定是非常重要的业务诉求。

比如一个最常见的情况，有很多线上SQL性能是有问题的，这些SQL会给业务稳定性带来一定的风险。

那么，我们能不能通过产品主动对线上有问题的SQL进行主动诊断，提前做优化，而不是SQL引起故障后才去优化。

（4）智能异常发现。

线上业务负载不断地变化，业务行为、用户行为也在不断地变化。

传统基于阈值设置报警的方式无法可靠、及时地发现数据库故障或者异常。

如何可靠地去发现数据库异常，甚至是提前预测到故障的发生并进行及时干预，是有很强的业务需求的，但同时也有非常大的技术挑战，尤其是在阿里这么大数据库规模场景下。

（5）容量预估。

还有一些业务诉求是容量预估的需求。

比如什么时候需要扩容，如何更精准地对数据库容量做出预估，这些后面我会稍微展开一下。

2、用户诉求另外一部分诉求是使用数据库这些人的诉求，也就是我们的开发人员。

每个公司数据库服务方式有所不同。

这里我列了一些开发人员经常会问到的一些问题，这些问题背后的诉求让我们思考我们的产品站在开发者的角度，要解决什么问题。

在业务发生异常时，需要快速定位到整个链路到底哪块出了问题。

之前DB对于开发者来说是一个黑盒，不管是信息透明方面，还是大家对数据库领域的知识方面，对于DB的了解程度可能都不够，不知道DB是什么状态，发生了什么问题。

具体来讲用户诉求主要有：（1）信息透明，自助优化。

我们期望用户能够自助发现和解决数据库的性能问题，并非发现问题先去找DBA，这样整个流程会比较长，时间成本也比较高。

但做到自助化，首先用户能够全面了解数据库的运行情况。

（2）持续优化。

只要业务在线上运行就会不断的变化，业务负载不断变化、用户行为也会不断变化。

所以数据库优化是个持续的过程，并不是今天发现一个问题解决了，以后就不出现问题了。

尤其是互联网的应用，持续优化尤其重要。

（3）量化跟踪，流程闭环。

开发人员经常会问到一个问题，上次帮他做的优化，结果到底怎么样。

我们知道并不是每个优化都是实际有效的，因为很多优化方案是基于当时的信息和场景做的一个判断，实际优化结果只有当应用之后才能真正去做评估、做衡量，所以我们要提供量化跟踪和评估的能力。

另外，我们期望整个优化流程，从发现问题到最终解决问题在产品内能够闭环，开发人员能够自己完全自助化走完整个流程，而不需要DBA的参与。

流程闭环也是产品必须具备的能力。

（4）输出产品，而不是人。

不断有新的业务上线，而我们的DBA就这么多人，并且每个人有不同的侧重。

对于一些快速发展的业务，在早期我们可能没有DBA去做特别支持的，但这些业务的数据库反而是容易出问题的。

开发人员如果能够通过产品解决问题，而不是凡事都去找DBA，解决问题的效率会更高。

将我们DBA的能力通过产品进行输出，更好去支持我们的业务。

未来数据库优化服务会从自动化发展到智能化，这是我的判断。

今天仍然有很多问题是解决不了的，比如精确的容量预估，智能的异常发现，故障提前预警等。

现在我们有非常多的数据，也有数据加工分析的技术，所以我们开始进行一些探索，通过数据分析和机器学习等技术手段来解决之前解决不了的问题。

比如最简单的容量预估，每年都会做预算，做容量预估。

至少我现在还没有看到特别多的公司去用很科学的方式，完全基于业务目标以及历史数据的分析来做容量预估。

很多时候容量预估是靠拍脑袋决定的，但是今天有了大量的数据和加工数据的技术手段，我们是不是可以做更精准的容量预估。

举这个例子来说明一下，未来很多的优化应该向智能化方向去思考，去探索。

CloudDBA在阿里大概是这样的一个发展历程，我们今天还处于自动化阶段，但同时也有一些智能化的实践。

未来我的判断是一定向智能化去走，后面会在这方面尝试更多的探索。

说了这么多，CloudDBA到底是什么？这有一句话：“CloudDBA是一个数据库智能优化产品，面向开发人员提供自助化诊断优化服务，致力于成为用户身边的数据库专家。

”CloudDBA不是给DBA开发的工具，从一开始我们的用户定义就很明确。

我们是面向使用数据库的开发人员提供这种自助化的诊断优化服务，我们的用户不是DBA，而是真正使用数据库的开发同学。

面向DBA和面向开发同学对产品来讲是完全不同的概念。

比如开发同学没有太多数据库背景知识，我们即使做简单的信息透明，也需要做一些翻译，能够让开发同学理解。

用户定义不同，数据的加工、分析以及最终的呈现，都是完全不一样的。

接下来讲一下CloudDBA到底能做什么。

这是我们简化版的整体架构，涉及的面比较广。

从下到上分为四层：（1）最下面是我们的采集层。

对所有数据库进行实时的秒级数据采集，包括性能指标、日志数据、SQL流水、DB内部的一些信息等。

（2）采集完之后数据到达计算层，计算层分两大块。

一部分是实时计算，对于SQL流水、监控指标等，都会做实时计算和展示。

另一部分是离线分析，比如性能基线、读写热点、统计报表等。

（3）再往上就是数据库诊断服务层。

如果大家做过系统的数据库优化，就清楚数据库优化会涉及到很多方面。

最常见的就是SQL优化，SQL是不是很慢、有没有走到最优路径、SQL写法是否合理等等。

SQL相关问题是我们开发经常会遇到的。

还有其它一些问题，比如说空间、会话、锁、安全、配置等，CloudDBA能够对DB的每一个方面提供相应的专家诊断服务。

（4）最上面是接入层，在阿里内部通过企业数据库服务平台iDB作为入口向开发同学提供数据库优化服务。

接下来跟大家分享一下我们做这个产品的一些产品设计原则。

如果大家也在做类似的产品，希望能够给大家一些参考。

之前我们数据库优化主要是DBA来做，但DBA人工优化不具备扩展性，CloudDBA第一个设计原则就是要提供自助化服务，希望整个优化过程只有开发参与，并且整个优化流程能在CloudDBA里实现闭环。

由于业务负载会不断地变化，需要对所有线上数据库进行持续的主动诊断，及时发现和解决数据库性能问题。

另外，这个产品需要有全局的视角，能够从全局角度发现规模优化点，具备规模优化能力，并且能够量化规模优化的收益。

还有最后两点非常重要，首先就是数据驱动。

从我个人理解，今天要做这样一个优化产品，首先要有足够的数据，然后用数据分析和挖掘的技术手段，再结合数据库领域知识，给出更合理的诊断优化建议。

智能化是我们对于数据库优化产品未来发展方向的判断，也是我们一直在坚持探索的。

时间关系今天无法全部展开，接下来重点展开几个方面。

一个是CloudDBA的SQL优化怎么做的，还有一个是空间优化，另外就是CloudDBA全量SQL采集和分析。

最后会分享一下我们在智能化方向的探索。

SQL诊断先说一下SQL优化，不知道大家平时做SQL优化时是怎样的流程。

大家回想一下，你是怎么发现哪些SQL需要优化的？要知道优化什么，为什么要优化它，然后再考虑怎么去优化。

还有一个问题是优化完之后效果到底怎么样，是不是真的有效。

整个优化过程不管是开发还是DBA做，都需要形成一个闭环。

CloudDBA实现了这么一个闭环。

第一步决定哪些SQL需要优化，第二步是如何优化，第三步是优化后效果如何，要做量化跟踪，确认是不是有效。

如果发现没有效果，再次重复这个优化流程，直到问题被解决。

这是SQL优化的大概流程。

我们实现了一个类似MySQL优化器的What-if optimizer。

举个例子说明一下What-if optimizer是什么。

比如一条SQL查询有10个可选的访问路径，MySQL优化器目标是要从这10个路径选择访问代价最低的一个路径。

而What-ifoptimizer要做的事情是如何规划出第11条路，让这条路比现有的10条路都快。

难点在于这条路是不存在的，这个路怎么修，修完之后是不是真的更快，这些是What-if optimizer要解决的问题。

比如一个常见的SQL优化手段是索引，那建什么样的索引会比当前所有执行路径都好？这是我们的SQL优化引擎要解决的问题，也是我们产品比较核心的部分。

大家可以看一下这个流程，前面几步跟MySQL或者其它优化器类似，但后面的候选索引生成，代价评估，优化建议合并等都不一样。

我们的输入是一条SQL或者一个SQL workload，输出是对应的优化建议，比如新建索引、SQL改写等。

SQL优化最关键的是要有全面准确的统计信息作为输入，另外就是它不能是规则式的，因为SQL的执行路径与数据分布有很大的关系。

同样一条SQL，数据分布不一样，实际执行路径可能会完全不一样。

SQL优化这块有几个关键点需要强调一下：（1）全局视角。