导语 | 虽然数据库上云解决了传统数据库很多问题，但如何让云数据库发挥最优的效能，依然充满极大挑战。为解决这一难题，高速发展的云数据库正在走向“自治”。本文是对腾讯云数据库高级产品经理刘迪在腾讯云开发者社区沙龙online的分享整理，为大家带来腾讯云在数据库自治服务领域的探索和实践，希望与大家一同交流。

一、数据库自治的演进

上图所示是一张关于数据库自治的宏观视图。

业内普遍定义的石器时代大概是在十几、二十年前，刚刚进入数据库发展的快速轨道，当时的技术方案和对于数据库的认知都处于一个初级的阶段。

经历了后续的工具时代、专家时代，现在数据库自治已经到达了智能时代。在智能时代中，我们享受到了数据库自治在数据库性能优化、管理、服务等红利。

很多人都有疑惑，这条时代发展的时间线到底是怎么演进的？其实这个问题不难理解，大家在日常工作中也能体会到，时代的更替、技术的诞生，往往跟业务的需求有关，也跟现有的技术能力有关。

无论是业务驱动还是技术驱动，最终的结果就是使得数据库自治从石器时代到工具时代、专家时代、智能时代，这样一个井然有序的发展过程。

我们所谓的石器时代、工具时代、专家时代、智能时代其实不仅仅是指代时间的迭代，更多的是指技术的发展和趋势的迭代。所以有些公司现在可能依然处于石器时代，有些公司可能很早就进入了专家或者智能时代。

1. 石器时代

首先我们来看石器时代解决了什么样的问题？石器时代数据库运维和服务领域关注的问题是什么？

最明显的一个特征，石器时代关注的问题就是“没有问题”，也就是保证业务不出问题，没有问题就是最大的成功。

因为在石器时代，运维依靠的主要是纯手工的人力，靠数据库运维工程师没日没夜进行手工的运维操作。

在这个阶段，往往是有经验的DBA带一些刚刚入门或者刚刚毕业的同学，传帮接代的进行知识传递。这样造成的结果就是整个团队的资质水平参差不齐，但整个团队还是可以承担起公司业务线数据库运维的重任。

石器时代最大的目标、最大的收益，就是知识的积累，但积累的大部分是碎片化、零星化的知识。

2. 工具时代

在工具时代，关注的焦点从“不出问题”，转变为“在不出问题的前提下如何提高效率”。工具时代不再是原来的手工录入代码、手工处理问题，而是开始把经验、知识沉淀成脚本或者工具。

目前大部分公司的数据库运维有可能是专人专岗，也可能是由研发同学兼职，他们会用自己写的工具或者网上开源的工具进行运维工作。这个工具可能是一个很简单的脚本，也可能是非常复杂的命令集合，这是数据库运维中一个必不可少的过程。

在这个时代中，大家关注的焦点是怎样用工具去很好的满足业务的需求。

除了人和工具之外，能帮助大家提高效率的还有流程管理。在工具时代，看重的一点是流程管理如何把人和工具结合在一起，提高数据库运维的效率。

在这个阶段会出现大量审核的系统、流程和服务，每个审核都有着非常规范的流程来进行数据库的运维。

3. 专家时代

当工具时代的积累达到了一定的程度，就到达了专家时代。

在这个时期，大家发现之前的脚本虽然很多但很杂乱，用了各种各样的编程语言、运行在各种不同的环境中，没有统一的管理平台，也没有统一的归类整理。数据库运维的水平往往取决于写这个脚本的运维工程师的个人能力，很难很好继承下去。

所以专家时代更多的是想把脚本标准化，用服务平台代替杂乱无章的脚本，从而将脚本规范化、标准化，变成一个可以实现自动化运维的平台。

通过这个平台，无论是有资历的工程师还是刚刚入门的研发同学，都可以井然有序的根据平台化的服务进行数据库管理。

把专家的经验转变为可复制的能力工具，是专家时代运维最显著的特点。

4. 云数据库时代

随着近几年云数据库时代的到来，很多企业从自建DB迁移到了云上，也开始认知到云带给大家的好处。

数据库从本地部署到云上，可以自建云服务器，也可以直接使用云上提供的PaaS服务。这部分无论是关系型数据库还是非关系型数据库或者是NewSQL，大家都开始逐渐享受到云数据库时代的红利。

在数据库上云后，很多人会问云厂商提供的服务是不是可以保证数据库的运维没有任何的问题了？就不再需要去思考、不需要拥有之前一代代继承下来的经验？

其实并不是这样。数据库上云解决的只是基础的管控服务，比如备份、监控、故障切换等等，云上提供的是相应的PaaS能力、高可用能力和数据可靠性的能力。

但其实云服务的到来，对数据库的运维服务反而提出了更多的挑战。这里我们可以举几个例子。

首先是资源的评估，这是在上云、多云的使用中会经常遇到的问题。本地使用的是4核16G的物理机，那么在云上要购买哪种型号的服务器？购买哪种规格的PaaS数据库服务？绝大多数没有经历过云迁移的同学在这个阶段会认为最好的方法是平移，这样一定不会出现问题。其实不然，在某些环节出现的问题有可能会导致业务性能出现故障。

其次在上云之后，大家会认为云的弹性伸缩促使了业务的快速发展。近两年来很多的电商业务量、访问流量都呈几何倍数增长，各种各样的大促节日让业务部门、数据库运维部门面临更重的数据库保障任务。这时要如何保障资源评估的准确率，以及快速处理突发事件就成了要解决的问题。

同样对于云上的数据库，最大的变化就是上云之后变成了黑盒。这种黑盒现象使得在故障诊断、分析和恢复数据库问题时不能快速的定位问题、发现问题、解决问题。

所以云上数据库时代到来以后，对数据库运维同学其实是提出了更高的要求。对于非专业的运维同学，如何通过云上成千上百的异常指标来发现问题、找出规律，是面临的一个大问题。

最后，云时代还对性能提出了新的考验。如何利用经验帮助提高数据库的性能，并且持续不断的进行优化？随着数据量的积累和业务的增长，甚至一些数据的变化导致的数据分布不均衡，都会导致数据库出现问题，所以数据库性能的优化在云上有着更大的挑战。

5. 智能时代

正因为上面讲到的原因，促使运维从原来平台化运维，不得不推进进入智能时代的发展。智能时代大家不再是人和工具的结合，而是人、云资源、以及自治服务的结合，从而提供更好的数据库运维服务能力。

这个阶段的目标是数据库能力和专家经验的共享，能够把之前已经积累好、沉淀好的数据库处理经验自动化，能够让数据库自己处理一些简单的问题，不需要人工干预。面对复杂问题的时候能够提供非常充足的建议，通过专家的干预进行最后的处理。

在云时代也要通过自治服务帮助大家获取数据库目前存在的看不见、摸不到的隐患。比如查询操作，当一个表只有十行数据的时候，无论怎样查询返回速度都会非常快、CPU 消耗也会非常小，但一旦并发上来，比如数据量增长到十万、百万量级的时候，原来看起来非常快的 SQL 就都变慢了。

在故障没有发生前，如何通过自治服务帮助用户在隐患阶段就能解决数据库的潜在问题，这就是数据库智能时代主要关注的焦点。

类比自动驾驶的等级，我们把数据库自治运维也切分成 Level 0 ~ Level 4 这几个阶段。

最开始所有操作都需要人工部署、人工干预，而后期人只是作为辅助，一些简单的工作、没有成长、重复的劳动都可以交给数据库自治服务统一完成。

经常有人会问，数据库自治服务是否会取代人工？取代数据库运维？取代DBA？我可以很明确的告诉大家，数据库自治目的是为了提高处理问题的效率、提高业务的稳定性、降低业务的故障导致的损失，而并不是为了取代DBA。

DBA在数据库各个发展时代的核心价值，从会写自动命令到会编写脚本，处理线上的故障、会排查日志，再到会做一些监控和管控平台。到了数据库自治时代，数据库运维核心价值应该是能够贴近业务，在业务层面发挥更多的价值。能够通过积累、通过对业务的理解和数据库的理解，帮助业务在架构设计、附表设计、整体的业务架构上面做更多的工作。

所以数据库自治服务是放大了数据库运维的核心价值，而不是取代了数据库运维。

二、腾讯在数据库自治中的探索与实践

腾讯在数据库自治中的探索跟整个行业的历史发展一样，同样是从简单的运维系统雏形，到后面随着业务体量越来越大，包括微信、腾讯视频、红包业务、腾讯游戏产业、腾讯体育这些大业务不断的扩张，使得人工操作遇到了瓶颈，成本也到了需要转型的阶段，因此数据库自治平台从内部开始逐渐孵化。

因为腾讯自身业务的行业属性非常多，有内容线的行业属性，有社交类的、有文体类的等等，根据不同的使用场景不断打磨后，去年开始对外发布 —— 数据库智能管家DBbrain，这是腾讯对外发布的一款强大的数据库自治产品。

1. DBbrain 产品能力解读

DBbrain 服务在云上是免费的，大家可以进行免费的试用。DBbrain 提供的自治服务涵盖三个方面：

• 性能优化：利用机器学习、大数据手段快速复制资深数据库管理员的成熟经验，将大 量数据库问题的诊断优化工作自动化，服务于云上和云下企业。
• 安全防护：提供从用户行为安全、SQL 安全到数据存储加密安全等多项数据安全服务， 公安部认证的等保合规性安全产品。
• 数据库管理：提供免安装、免运维、即开即用、多种数据库类型与多种环境统一的 web 数据库管理终端。

数据库智能管家 DBbrain 与传统数据库管理工具的区别在于，它不仅仅作为辅助运维工具供 DBA 使用，而是面向所有用户，包括运维团队、开发团队、运营团队。其核心思想是通过智能运维平台为应用部门提供标准化和自动化的数据库运维服务。

2.  DBbrain系统架构解读

数据库智能管家 DBbrain 提供的自治服务是跨数据库引擎的，是通过多数据库引擎插件式方式提供的，不仅支持 MySQL，也支持 NoSQL、Redis等。

之前大家在网上听过Oracle有自治数据库、微软也有自治服务，但他们的服务是在特有引擎上进行数据库自治，并不是多引擎的的服务平台。

我们认为数据库自治既然是为了帮助数据库运维同学减轻工作的压力、提高运维的效率，应该是具备涵盖数据库运维所涉及的尽可能多的数据库引擎，因为一个业务可能不止会用到单一的数据库，比如常见的 MySQL + Redis 组合等。

在数据的采集层，以 MySQL 为例，我们会根据不同数据采集监控指标、比如主机监控指标、网络监控指标、数据库监控指标，通过秒级监控的指标以及采集的日志信息，帮助用户发现更广的问题面，不仅仅是数据库层面的故障、主机层面和管控任务的故障都可以有丰富的源数据的记录。

在数据的计算和加工层的模块，模块通过流式计算平台提取出特征数据。这个地方并不需要人工进行分类，而是通过特征提取和加工来识别出异常信息、异常的数据，再进行异常指标和异常趋势的预测。

这个模型我们自身已经训练出了涵盖比较多指标和比较多情况的通用引擎，另一方面，也通过了现网用户对数据库使用情况和对于问题的反馈来进行监督式学习，不断增强模型训练，做到模型对业务是千人千面，而不是一套通用模型面对所有的数据库业务。

在实时诊断模块中，通过计算模块给出的结果、识别出的异常信息，以及内置的专家智能服务来为大家提供诊断优化的建议，同时会调用一些运维工具类处理的模块，比如慢日志分析模块、延迟主备切换分析等等，以工具类的模块进行辅助诊断，给到用户非常精准的数据库问题的诊断结果和对应分析以及优化定义。

在功能和输出交互层面也提供了多终端的访问，不仅仅是PC端的访问，也提供了小程序、移动端、公众号、订阅号一体化的输出，帮助用户有各种各样的体验，在任何地方都可以享受数据库自治服务带来的红利和便利。

3. 用户级监控告警全链路

接下来和大家分享这几年我们做了哪些工作，有了哪些沉淀积累。

数据库自治服务首先关注的是故障，故障具体关注的是告警和监控，DBbrain 提供了宏观用户级别的监控和告警，让用户第一时间内能够发现故障、发现异常，可以了解整个自己负责的所有数据库的情况。

这部分采用的是二八原则，产品基本上为80% 以上的”小白”设计，涵盖80% 常见的数据库异常问题和监控指标，所以门槛非常低。

监控页面给用户呈现出来的易读性非常高，不需要从几百个监控指标中找出哪个有问题，我们会帮助用户筛选、聚合出相同问题触发的监控指标。

最后是过程+结果的导向，DBbrain 的全景视图是联动的，所有都是结果导向，不仅仅让用户看得到实际上出现什么问题，也可以在监控告警层面给大家展示故障发生过程中的变化，性能变更趋势、其他指标变化趋势等等。不仅是在结果侧方面给出反馈，在过程方面也会给用户清晰的呈现。

4. 7*24小时异常诊断

7x24 小时异常诊断，就相当于不间断的 DBA 值班一样，只不过是通过数据库自治服务来提供。

在之前的专家时代、工具时代，没有办法做到 7x24 小时的异常诊断，主要有三个原因：

• 信息分析难
• 信息获取难
• 性能优化难

数据库自治服务可以帮助大家克服掉这三座大山，提供自治的闭环服务，帮助大家识别各种各样的数据库问题。这里我们可以举几个例子：

比如在线教育行业由于疫情的原因，在晚上八点到十点会是一个业务高峰；而交易类、金融类的业务在早上和下午会是高峰，在某一个点可能会出现峰值，所以具备一个周期性的变化。

变更是指原来的业务变化是有规律的，但是突然有一天出现业务的变更，这很可能是业务进行了功能上的发布或者调整。

通过这些特征提取以及采集到的多维度秒级监控进行相互的配合，能够帮助识别出每一类业务自有、特有的规律，使得在做归因分析和自我优化过程中，可以屏蔽掉由于自身业务特性带来的并非是故障的高峰点，帮助用户识别“伪高峰”。

5. 异常框架诊断

数据库自治服务诊断的框架分三部分 —— 假说生成、证据评分、决策计算。

在假说生成时，我们会把各种关系模型进行1-N个关联，取到非常多的相关指标和异常，通过决策候选集的筛选，利用证据模型通过证据链进行筛选。最后通过决策支持度向量，进入决策计算模块。

决策计算模块会进行判断，决策是否为最优，如果不是最优会重新进行证据评分。

6.  SQL 优化

相信 SQL 优化是绝大多数 DBA 或者研发同学都很感兴趣的话题，也是大家用的最频繁的功能之一。

DBbrain 提供的 SQL 优化，特点在于代价和成本。不仅提供索引的建议，还会提供语句的改写和排序字段的选择。

DBbrain 在索引分析方面考虑的更为全面。比如在增加索引时，会考虑是否有冗余索引，是否有现成的索引可以使用或者修改。其次在索引更新后，还会评估对于用户已有的SQL是否会有影响，从而使得数据库性能下降等？

此外像大家比较关注的 SQL模板聚合统计、耗时区间统计等多维度的信息统计，DBbrain也会提供相应的能力。

7. 基于cost的分析引擎

基于 cost 的分析引擎也是我们今年的重点之一。首先的出发点是增加用户对于 DBbrain 提供的索引建议的可信度。

往往我们要判断一个索引、一个优化建议好不好，最简单的方法是理论上一定是可行的，二是实践，如果加上去真的变快了，我们就认为这个处理得好。如果加上去没改变就不行。

但是通过基于 cost 的分析引擎，我们能够在用户没有执行优化建议之前就把优化的结果告诉大家，从而在优化前就可以清楚的看到预期的优化效果。

cost 值不等同于耗时，减少的 cost 不能等比例的计算耗时。这里我们会考虑三个方面：

• 在Server层中主要的开销是计算符合条件的行的代价
• 在engine层中主要的开销是从磁盘读数据的代价
• 在Jion计算时不仅要考虑condition,还要考虑condition上的filter

我们会将这些综合到 cost 引擎中，帮助用户更好的在优化之前看到优化的预期效果。

8.  数据库审计与分析

这个功能也是 DBbrain 提供的非常前沿的功能，也是非常实用的功能。

具体就是我们之前有些操作很可能是瞬间的操作，在回溯问题时发现不了；有些SQL由于记录的原因记录不全，导致分析问题时没有参考。

通过SQL审计与分析服务，可以帮助用户记录所有在数据库层面执行的 SQL，不仅仅是变更的操作，查询操作也可以被记录下来。可以理解为类似于原生的 log。首先对性能消耗做了严格的测试，每条SQL执行完以后会进行审计规则的识别和过滤，将命中审计规则的 SQL 写入到内存中，批量的进行刷盘，它的性能整体损耗在做压缩以后，得出数据是低于5%。

各个厂商都在做审计类的服务，评测报告也是网上可以查询到的，5% 的消耗是业内很领先的水平。

针对审计全量SQL能够做的事非常多，能够贡献所有SQL任意时刻的快照以及执行的趋势。很多时候一条SQL可能就执行十秒，但其中等了20秒，所以SQL执行时间很短，但是这条SQL结束的时间跨度非常长。对于这种SQL如果没有全量时间的快照就很难发现这样的问题，这帮助我们在排除疑难杂症的时候有更多的支持，能够帮助我们把整个数据库执行轨迹更加精确的梳理出来。

9. 数据库健康评估策略解读

除了精确到SQL层面的优化，数据库自治服务在宏观上对整个数据库也有一套健康评估策略，主要通过五个方面进行评估，如下图所示：

首先是可用性，可用性是指服务正常还是不正常。业务最明显的感知就是业务是不是挂了，是不是可以正常的使用。

第二是数据可靠性。什么情况下会影响数据可靠性？除了故障数据、丢数据、人为的操作导致数据的不一致以外，有时候正常的业务逻辑中也会出现数据可靠性的问题。比如数据延迟增加，一旦出现故障如果主库的数据无法找回、起不来，备库的数据就会出现数据丢失的情况，很可能是由于binlog还没有传输过去、或者主库事务没有结束的情况。

性能是指是不是存在慢SQL、是不是存在并发数导致 CPU 资源消耗过于明显，是不是使用率非常高、发挥功能不足或者是 cache 比较低等等导致的性能问题，也是数据库健康评估策略非常关注的一点。

还有就是隐患、超大表或者是表数量的不合理，没有及时进行分步、分表，或者是采用分布式底层存储的架构，导致在做大量数据的排序查询时性能会随着数据量逐渐增大，聚合的消耗会越来越大，这也是隐患项。还有一个隐患是权限是否合理、是否有过多的授权，这些都会涉及到数据库的隐患，我们也会在健康评估策略中特别的强调出来。

变化我们在7x24小时的异常诊断中提到过，业务趋势的变更、突增、变化，与之前业务消耗和业务资源使用情况不一致的情况，我们都会识别出来告诉用户，帮助大家不仅能够掌握整个业务的使用情况，也可以对业务资源消耗画像有所了解。通过健康评估报告，更能够知道各种业务是否合理。

10. 时间序列模型Porphet在资源预测上的应用

刚刚我们提到，我们结合了一些算法进行了一些预测，预测模型是采用前几年Facebook开源的Porphet算法，应用累加回归的模型，通过时间、趋势以及循环变更的规律来帮助业务预测资源的使用情况。

最简单的是根据历史使用趋势预测磁盘使用量，能够帮助用户提早知道什么时候该扩容、什么时候缩容、什么时候需要购买更多的设备、什么时候需要清理数据，同样也可以帮助用户预测CPU、内存性能指标在后续趋势中的变动，帮助用户在大促前、一些活动之前、一些重要敏感操作之前，知道业务什么时候是低峰、什么时候需要拓展多少资源，这种预测模型对用户和云厂商有非常大的价值。

对于云厂商而言，对于资源调度、资源的管理以及帮助用户进行资源合理的分配，有非常大的价值。

对于客户而言，云上的资源评估、资源的管理工作，借助预测模型可以预先启动这些工作，不用每次都措手不及。想要扩容的时候马上申请资源是来不及的，虽然云上是弹性的伸缩，但是特殊情况下，比如出现大促的时候，电商客户都在这一天发起扩容，很可能就会出现资源洪峰，用户可能不能够按时拿到想要的资源。

11.  自动性能优化系统 CDBTune

CDBTune 是一个新的前沿技术，去年我们在 SIGMOD 以论文的形式进行了发布。产品化的过程也在进行逐步的完善。

大家都知道数据库参数很多，那么要如何调参？很多人表示网上有很多万能模板，但到底适不适合你的业务，其实是不知道的，可能无法发挥数据库最大的性能。

如果对这些参数进行手动调参，有经验的DBA可能对其中的某些参数有自己的经验，但对于各种不同特征业务或者不断变更的业务，CDBTune 就可以帮助很好的解决这个问题。

我们可以通过深度学习算法通过自调优的方式，得到与自身业务相匹配的参数配置。调优的时间也比其他的要快，调优的结果经过测试，已经达到了很高的水平。

12. 容易被忽略的数据库安全防护

绝大多数的数据库运维对于这部分的内容要不然是接触的很少，要不然就是会被忽略掉。大部分的数据库运维往往认为只要保证业务不出性能问题、不出故障就可以，但很少会关注数据库的安全防护。

数据库自治服务作为一个全方位的服务，必然要在大家忽略或者没有关注到的地方提供相应的价值，这样才能为客户更好的提供数据库的稳定性和安全性。

这里我们主要提供了三个功能：

• 合规审计：提供符合国家等保要求的安全审计，对企业网络中的数据库各类会话信息、访问操作、SQL 语句进行安全审计，可挖掘数据库运行过程中各类潜在风险和隐患，为数据库安全运行保驾护航。
• 安全治理：可对数据资产、数据内容、访问信息进行中心化管理。并依托先进的 AI 引擎与敏感数据发现算法， 将针对企业核心数据的异常操作进行筛选告警，实现企业数据保护。
• 数据脱敏：以处理数据库文件的方式，对数据库中敏感数据进行在线屏蔽、变形、字符替换、随机替换等脱敏操作，达到企业核心数据保密效果。

三、DBbrain行业典型案例分享

下面我们结合一个行业用户的案例，来给大家进一步分享数据库自治在实际的生产过程中如何应用。

电商大促大家都不陌生，腾讯云自身也支撑了非常多的大规模电商。那么电商在每次的大促过程中，如何利用数据库的自治服务，来保障自身的数据库安全？

在备战阶段需要进行故障梳理、资源评估等工作，在没有数据库自治之前，这些工作都必须由DBA来进行。一旦在某个环节出现了问题，或者业务出现了问题，往往DBA就变成了“背锅侠”，总能找出DBA的问题。

而使用数据库自治服务就可以有效解决上述问题。

1. 数据库巡检，评估风险

首先，我们可以通过数据库巡检全量的实例，评估相应的风险。因为电商行业的实例很多，如果让DBA手动巡检，工作量是非常巨大的，所以常规DBA会进行核心实例的巡检，或者只对经常出故障的实例进行巡检，但这样就会有很多潜藏的风险。所以全量巡检、多维度巡检是非常必要的。

为什么说在这个地方可以发现问题？因为在备战阶段业务侧一般会封网，一旦封网，业务逻辑不到必要的bug修复时是不会调整的。所以在封网后进行全量巡检、排查问题，只要修复了那么在之后大促的过程中，就可以尽可能的减少问题。

数据库自治的巡检报告，包含从基本信息到资源状况、任务状态的巡检，以及日常的访问行为等非常全面的信息。

热点访问是非常关键的，很可能业务没有出问题，但冷热数据一旦没有进行区分，那么在并发量高的情况下一定会出问题。所以我们可以在用户封网后提供全链路的检查。

2.  助力业务优化改造

在排查之后，我们还需要助力客户进行业务的优化。如图所示，我们把优化大致分为五层。

其中，SQL优化是大家非常容易上手、操作起来非常方便的一个优化，比如索引优化、改写优化等。其次还有更深入的配置优化、数据优化、架构优化和业务优化等。

之所以排为1-5，是因为在第一层的优化中，业务的配合度会比较高、改动比较小，随着逐渐深入，可能就需要业务侧更改代码逻辑。我们会根据业务不同的需求提供相应的优化建议。

3. 业务场景的故障自愈

最后，我们发现还有一些问题。比如大促中临时的变更发布，导致因为数据库层面没有相应的应对措施，数据库被击穿或者压力很大。还有可能是低质量的SQL，在压力和数据量激增的情况下数据库出现问题。

面对这种情况，传统的方法一般是直接kill掉对话，持续kill或者定时kill进行降级。如果无法降级则进行重启或者HA切换，或者进行业务侧的应用回滚或者临时降级，但相对来说实践起来比较困难。

数据库资质DBbrain在这个时候就可以发挥作用。首先7x24小异常诊断与优化，可以在还未发生问题时就发现隐患，并提出优质的解决方案。此外，还提供了高并发场景的解决方案，并且可以自动持续的kill掉阻塞的SQL。

4. 高并发场景解决方案

刚才我们提到，DBbrain在高并发场景提供了数据库性能优化以及降级止损的解决方案。方案具体有三项：

（1）热点更新保护

在高并发场景中，经常出现对同一行数据的更新，在没有缓存的情况下，都会打到底层的数据库。为了保护和减小开销，针对语句的排队机制，尽可能把具有相同冲突的语句放在内存队列排队，通过开启热点更新保护来减少锁冲突的开销，提高高并发场景的数据库性能。

（2）SQL限流

顾名思义，就是帮助用户进行业务降级。限流的操作类似于改写，但技术方案不同。可以通过创建 SQL 限流任务，自主设置 SQL 类型、最大并发数、限流时间、SQL 关键词，来控制数据库的请求访问量和 SQL 并发量，进而达到服务的可用性，不同的任务之间不会发生冲突。

（3）空闲事务自结束

自动结束(Kill)空闲事务，避免大事务未提交导致大量资源争抢。会自动识别开启的事务，如果开启事务后在一定时间内没有进行提交，会自动结束该事务。

四、数据库自治的未来展望

数据库自治在未来应该会朝着自愈、自优化的方向发展，不仅能自主调节索引建议，还可以自主创建索引，自动进行识别、添加和删除。

并且在未来还应该可以自动对执行计划进行回归修正，优化策略下沉与引擎融合，让用户需要干预的越来越少，提供的优化服务越来越多。

最后是能够自动识别并杀掉失控SQL，并阻止进行至优化完成，帮助数据库层面做更多业务层面的代码实现。

这些都是未来将要实现的功能，或者是数据库自治在未来能让大家看到的迭代或者技术点。

Q&A

Q：数据库审计功能很重要，特别现在等保也有要求。腾讯云数据库审计的功能是通过旁路审计，还是从proxy节点抽取日志？

A：腾讯云数据库的审计，是在内核层面实现的，并不像其他的审计功能需要外挂Agent，或者在接入机上安装采集的进程实现。

腾讯云的数据库审计，是在连接release之前，在语句提交之后进行规则匹配，如果命中规则便将内容转变成json，拷贝成审计的内容发回，批量进行Flush刷盘，最后存储到列式存储中，提供用户的查询，并且为数据库审计提供数据源。

在这个阶段，如果在return和连接release中间，审计规则配的比较复杂或者比较多，就可能会出现性能损耗，但这个损耗是非常低的，在5%以内。

腾讯云数据库的审计功能，与市面上其他审计相比的优势点在于，是通过内核侧实现，不需要再从旁路进行Agent审计，这样一是可以避免漏审，二是旁路审计抓到的只是SQL包，抓包解析有可能有些信息抓不到，而腾讯云数据库自治的审计除了常规内容之外，还能抓到SQL执行的一些相关信息，比如影响行数、扫描行数等。

Q：数据库走向自治后，DBA的工作内容有什么变化？

A：比如性能调优，故障恢复监控、帐号管理、实现高可用、数据备份部署、架构选型等，在数据库实现自治后，类似这些的重复、简单的工作都可以被协助实现。而DBA更多的会倾向于更有价值的、与业务侧结合更紧密的工作，类似于数据库架构师、业务架构师的工作。

Q：数据库的服务降级有哪些表现形式？

A：数据库降级服务主要有几种方式实现。比如SQL限流，用户最直观的感受是当SQL超过了数据库的承载量后，会被拒绝，在日志中会看到一个自定义的错误反馈。因为SQL限流是在语义解析器之后、优化器之前进行识别，当并发度超过我们设置的每秒并发，并且特征相符，就可以在进入优化器前进行拦截。另一种降级可以通过账号和权限来限制；还有一种也可以通过DBbrain“实时会话”中提供的持续kill来实现。

Q：DBbrain是否在SQL优化方面提供SQL优化预估的时间消耗？并且在提供索引建议的同时，提供一个按钮点击即可通过onlineddl手动建索引？

A：DBbrain现在给出的是cost分析。选择cost分析的原因，是因为cost更能体现出SQL在计算开销、内存开销、磁盘读取数据开销的代价特征，而时间往往是不准确的。比如在一个很空闲的系统中，执行一些比较费时的操作，时间往往很快，但一旦数据量突增、系统环境发生变化后，同样SQL的时间会变长很多，甚至是从量变到质变。而cost分析，哪怕是十行的数据没有加索引都可以识别出来，就会减少只通过时间分析导致的误判和影响。

对于提供点击的onlineddl手动创建索引功能，应该会在后续提供给大家，也是后续比较重要的一项功能，帮助完成从发现问题、定位问题、优化问题到最后执行，这样一个全链路的优化闭环。