薛高敏：谈到数据库始终离不开SQL，很多开发者在日常工作中都会接触到SQL。比如数据分析师、数据科学家、数据库开发工程师、数据库管理员、全站工程师、移动开发工程师等等。
用户在写SQL的过程中，由于不同数据库引擎，需要适配不同的SQL模板。导致用户的学习成本变高，执行效率变低。如果出现故障，企业没有兜底的方案。
请问过去和现在，大家用什么方式来解决这些问题？下面有请艾奥给大家介绍一下相关的历史和现状。
艾奥：在过去，数据库的运维工作主要依赖DBA，进行人工运维。因为DBA可以对自己负责的数据库及相关业务有很多了解。所以DBA可以针对性的优化数据库实例，解决相关问题。
在运维过程中，随着DBA人均负责的数据库实例越来越多。DBA基于运维知识和场景化，开发相应的自动化工具，进一步提高维护的效率和标准。
在云场景下，数据库实例支持的业务越来越多样化，数据库实例的规模也越来越大。企业依赖传统人工运维或特定场景的标准化工具，已经无法解决所有问题。
因此，在云上出现了更多系统化的数据库实例运维工具。它能对实例进行全方位的监控，基于实例的工作负载和性能数据，做出针对性的更新定位。结合机器学习算法，对实例进行调优，达到数据库实例自制的目标。
在阿里云自制服务DAS上，针对SQL的相关问题，例如索引缺失、SQL不优等，进行了相应的优化。在空间问题，容量评估、负载问题和数据安全方面，都有相应的场景化分析工具和智能化的策略。
薛高敏：请问可否从某个常见的问题入手？带大家深入了解，DAS带给用户的价值有哪些？
艾奥：接下来，以慢SQL的场景介绍一下DAS的功能。慢SQL通常以执行时间的RT或扫描行数作为判断标准。例如执行耗时超过一秒的SQL语句，可以被定义为慢SQL。
因为数据库实例的会话连接数是有限的。如果慢ySQL的并发量较大，就会堵塞数据库的实例会话，从而拖慢正常SQL。如果这些SQL不能及时执行，会影响数据库实例对外服务的性能，从而影响整个业务。由于慢SQL对业务实例的影响较大，所以慢SQL治理是保证数据库稳定的关键。
针对上述场景，DAS对所有的实例提供7×24小时监控，用户可以时刻发现所有实例的情况。
如上图所示，DAS的异常检测有明显异常。通过对实例的实时性能分析，该实例的服务性能已经受到影响。
主要表现为它的QPS/TPS有有明显下降，数据库的连接数明显上升。此时，DAS会基于实例的会话数据和业务负载，给出指标异常分析结果，完成实时的慢SQL异常发现。
如何避免慢SQL进一步恶化，避免影响数据库实例的可服务性？为此，DAS提供了限流功能。
如果用户在DAS上开启资质服务功能，并且配置限流参数。该参数主要涉及SQL的并发度和自动执行的开关。开启该功能之后，DAS会基于当前会话，进行更新分析，定位出具体的慢SQL。
然后，结合用户配置，进行限流操作。从而有效阻断符合条件的慢SQL，缓解慢SQL对数据库实例的压力。
执行限流之后，QPS/TPS已经恢复，数据库的对外服务功能得到恢复。在执行限流的过程中，DAS也支持对当前会话列表中的慢SQL，进行kill操作，终止在会话列表中的语句，让数据库实例尽快进入正常状态。
薛高敏：限流操作主要针对业务高峰期，防止故障的应急措施。那么DAS如何彻底解决慢SQL的问题呢？
艾奥：系统出现慢SQL主要是因为没有执行正确的索引。例如某条SQL语句在执行过程中，进行全表扫描，导致了执行耗时过长。针对于这种情况，DAS会对执行的SQL语句进行分析，识别其中的查询条件、库表信息等具体内容。
然后，在数据库实例中，对需要的分析数据进行采样。基于代价模型进行索引分析，找出适合这条语句的索引，推荐给用户。
如果用户在DAS上，开启索引自动优化功能。DAS会将生成的索引建议，应用到数据库实例。
目前应用索引的时间，与用户配置的运维窗口相同，从而尽量减少对数据库实例的影响。
在应用索引之后，DAS会对实例进行24小时监控，确认新增加的索引是否真正有效。除此之外，DAS可以识别一些不高效的语句，并提供SQL语句的改写功能，让开发者基于改写建议，对语句进行优化。
薛高敏：上述功能是对已经触发异常检测的实例进行治理。如果存在相对较慢，但没有触发异常检测的SQL，如何进行识别和治理？
艾奥：针对批量的慢SQL，且没有达到阈值的情况，用户可以借助DAS专业版能力。DAS将用户的SQL workload进行记录，即全量SQL。然后，针对过去一段时间的SQL明细数据进行整体分析，识别其中可以优化的SQL。最后，做出相应的索引建议操作。
通过一段时间的SQL分析，可以找到其中更加优秀的索引组合。其中，涉及索引的新增和删除功能。对于可以改写的SQL，也能够提出相应的改写建议。
薛高敏：以自动驾驶的汽车为例，用户在启用自动驾驶模式时，最担心的是安全问题。对于DAS的自制能力，用户如何判断自助应用的索引是准确且不影响业务的呢？
艾奥：为了验证索引是否有效，DAS提供了SQL Review的功能。DAS主要采用流量回放的思路，通过备份、恢复或数据同步的手段，创建一个原实例的镜像实例。
然后，通过应用推荐索引，回放一遍原实例的流量。通过对比两个实例的性能指标判断建议是否有效。
流量回放能力不仅可以应用在索引对比场景，也可以应用在实例规格的编排，跨引擎迁移等等。
薛高敏：企业的实例数往往非常庞大，如何进行大规模的常态化治理，成为企业非常关心的话题。下面有请阿里云数据库研发专家鼎智，给大家分享一下DAS在企业级查询治理方面的探索与实践。如果大家需要发现问题SQL，有哪些方法？
鼎智：发现问题SQL的方法，通常可以分为两类。第一类，在上线前发现问题并进行拦截。具体做法是基于规则代码的静态分析。例如通过工具，静态扫描代码，识别代码里的SQL语句。
然后，结合库表信息，运用规则给出建议。但它的局限也非常明显，它无法识别代码中，通过程序拼接的SQL。除此之外，此类静态分析没有数据分布信息，它给出的建议是不准确的，尤其针对复杂的SQL。
另一种方式，在测试库上采集执行的SQL语句。通过SQL自动诊断，给出优化建议。这种方式有准确的数据分布，给出的建议更加准确有效。
上线后的治理，主要是有三类。第一类，是基于监控、报表和告警的全人工治理。第二类，是基于智能辅助系统，进行半人工的治理。辅助系统需要具备一定的归因分析能力，给出一些切实可操作的建议。第三类，全自制的智能数据库。它能够自我诊断、自我优化，全程无需人工干预。
目前，DAS完全覆盖了第一种和第二种方式。DAS作为一个智能辅助系统不断地迭代，提供更准确的归因分析能力。与此同时，DAS也朝着全自制的目标努力。
薛高敏：接下来，请具体的讲一讲DAS查询治理的设计思考和使用。
鼎智：DAS查询治理的主要目标是解决上线后的问题SQL。DAS以产品形态，发现并拦截上线前的问题SQL，需要和用户公司内的研发系统进行配合，其环境更复杂，并不适合公共云服务。
如果大家使用阿里云数据库，或者把线下数据库、ECS自建数据库接入DAS，就可以通过open API集成到用户的开发系统当中。从而在发布上线之前，运行测试，通过open API获取慢SQL，调用open API进行DAS诊断。
除此之外，上线后的治理分为两种情况。一种情况是出现问题，利用DAS辅助功能，快速定位SQL。大家可以使用自制中心的页面查看更新分析，快速定位，然后进行相应的处理。另一种情况，对于没有引发故障，但已经不健康的SQL，建议大家使用DAS的查询治理功能，进行处理。
鼎智：接下来，给大家做一个简单演示。如上图所示，大家可以看到查询治理功能，可以对问题SQL进行统计和趋势展示。大家可以通过这个数据报表了解实例问题的严重程度以及治理趋势。
这个功能源于阿里集团内部的治理实践。它的核心思想是把全部的问题进行离线分析。然后，将其分成两类。一类是无需优化的，一类是需优化的。
无需优化的问题，可以通过来源IP以及特殊规则，进行判断。需要优化的问题，会自动打上特色标签。例如有些SQL没有条件；有些SQL的扫描行数特别多；有些SQL是新增的等等。
基于个性化标签，用户可以进行更有针对性的优化，根据优化解决方案进行处理。与此同时，阿里云提供给用户自动打标功能，提供open API，方便大家进行系统的集成。
另外一方面，查看数据的用户和解决问题的用户用户，不一定是同一个人。在界面右上角，大家可以看到分享功能和导出功能。方便看报表的同学把问题分享给解决问题的同学。
另外一方面，查看数据的用户和解决问题的用户用户，不一定是同一个人。在界面右上角，大家可以看到分享功能和导出功能。方便看报表的同学把问题分享给解决问题的同学。
在默认情况下，查询治理功能仅分析实例的慢SQL。如果用户开通SQL洞察功能，查询治理将会分析全量SQL，尤其是全量SQL中执行错误的SQL。
如上图所示，可以看到所有实例执行错误的接口，以及错误码对应的链接。大家可以看到错误的原因。在未来，查询治理功能会支持更多的引擎，会考虑开放用户自定义能力。
薛高敏：DAS可以帮助用户在不花费精力，了解数据库运维知识的情况下，有效地提升SQL的执行效率。DAS降低了运维门槛和成本。达摩院也在不同方向发力，降低写SQL的难度，增加SQL相关开发的效率，优化SQL执行前的一系列步骤。
接下来有请达摩院智能数据库实验室的付晗博士，给大家介绍一下自然语言到SQL转译问题的最新研究进展。
付晗：自然语言到SQL的转译问题，其主要目的是，根据库表将用户输入的自然语言问题，自动转译为SQL查询。
这个问题主要的应用场景在于，让不了解SQL或者不了解表结构的用户，可以使用自然语言查询数据库，降低查询数据库的门槛。
这个问题有近50年的研究历史。早期被称为数据库自然语言接口，主要由数据库领域的工作者研究。
首先，利用自然语言的工具，把输入的自然语言问题，进行标注和解析。然后，把解析的中间结果和标注的中间表示，映射到不同的NL2SQL里。最后，把这些预测的NL2SQL成分，组装成一条合理的SQL查询。
这套方法有20年的研究历史。但它的主要缺点是需要设置较多的人工规则，并且只能支持特定的数据库。对于新给定的库表或者新的提问方式很难支持。
近几年，得益于深度学习和人工智能技术的发展。现阶段的NL2SQL的方法主要是端到端的神经网络模型，可以支持跨领域的预测。
在训练阶段和应用阶段的库表是完全不同的。目前，这些方法主要把NL2SQL当做一个，文本到文本的生成问题。它的模型输入是自然语言问题，库表关系模式，以及表中的值。模型一般使用编码器、解码器的框架。最终，使用端到端的方式输出完整的SQL。
现阶段的方法，根据预测结构的不同，可以分为两大类。第一类，基于语法解码器模型，它输出的是一个SQL的语法数。模型会按照数的便利顺序，逐个生成。另一类，是槽填充方法。槽填充方法是根据预先设计的多个填充槽，槽模型的输出目标是向每个槽中填充一个确定的值。
深度学习方法的主要优势是，可以有效地利用大量的数据，对于自然语言的灵活性支持较好，模型也可以在新的图表上使用。但它的缺点是，神经网络模型往往需要大量的人工标注数据，并且模型计算开销较大，成本较高。
薛高敏：达摩院的智能数据库实验室具体做了哪些方向的探索和解决方案？
付晗：智能数据库实验室从2019年开始，对NL2SQL相关领域进行研究。目前，主要开展四个方向的研究。第一，提升神经网络模型的效率。
目前最准确的NL2SQL系统都有两个特点。首先，它会使用一个复杂的语法，约束解码器，来确保NL2SQL语法的准确性。其次，会使用大规模的训练模型，保证语义的正确性。这两个复杂的模型，都会使整个模型计算的开销非常大。因此达摩院设计了一种新的预测方式，代替SQL的语法术。
这种方法不需要预测中间节点和系统的保留字，加速了模型的预测速度。目前，该方法可以在准确率不降低的前提下，只需要3G的显存和一个小规模的服务器，就可以运行。在相同配置条件下，可以把吞吐率提升5至10倍。
第二个方向，利用数据库领域的知识，提升SQL在语法和语义上的准确性。目前，神经网络方法主要在NLP领域推进，很少利用数据库领域的知识。目前，达摩院可以显著超过现有方法的准确率。
第三个方向，支持多领域的大数据库。目前，NL2SQL主流方法，它的假设都是一条自然源问题对应一个特定的数据库，里面最多只有几十个表。在实际场景中，用户会面临庞大的数据库，有很多个领域。
在这种前提下，现有的方法很难支持。因此，达摩院提出了库表定位技术，可以有效支持几十个领域、上千个表的大数据库，并且保证最终的准确率不会下降。
第四个方向，无监督的NL2SQL。神经网络模型需要大量人工标注的数据，标注成本很高。达摩院的主要目标是，不需要人工标注数据实现NL2SQL。
目前，达摩院的探索方向是通过简单的模板和数据库领域知识，实现大规模的训练模型。该方法不需要一条人工标注的自然源问题，就可以实现一个比较高的准确率。
