工商银行“ChatSQL”智能研发新工具探索与实践

随着工商银行业务的迅速发展和数字化转型的深入推进，应用系统的性能容量提升成为一项常态化的任务。工商银行使用数据库产品种类多、范围广、程度深，单一种类的数据库DBA从实践中获得的的调优经验往往在不同DBMS、不同负载场景之间难以复用，因此数据库性能优化的自动化在当前阶段是工商银行转型面临的一项关键技术挑战。

数据库SQL调优是优化数据库性能的关键方面，它涉及分析和优化SQL查询、索引策略和数据库配置设置，以改善查询执行时间和整体系统效率。传统上，SQL调优主要是数据库DBA的职责，日常调优过程如下：

（1）分析性能瓶颈：使用数据库自带或第三方的性能监控工具生成报告，比如 AWR报告和WDR报告，找出性能瓶颈和慢SQL。

（2）探查执行计划：通过数据库提供的执行计划（EXPLAIN语句），了解SQL执行过程中的不合理之处，如全表扫描、索引未命中等。

（3）重写查询：根据执行计划分析结果，重写SQL查询。例如，分解复杂查询、减少子查询、使用JOIN代替子查询等。

（4）索引优化：根据执行计划分析结果，为常用查询添加适当索引，移除不必要的或低效索引。

（5）验证和测试：对优化后的查询探查执行计划或进行性能测试，确保其在实际场景中表现优良。

实际性能调优场景中，由于难以直接在生产环境进行调优，且研发测试环境和生产环境存在数据量和硬件配置等差异，在一个环境上有效的优化方法可能换了环境后就失效，从而使得调优过程更加复杂。其次在转型过程中，由于设计理念的差异，不同数据库的优化方法并不完全通用，要经过专业培训和大量实践后，国产数据库DBA才能逐步成长起来。最后，当出现数据库性能问题时，留给DBA进行SQL调优的时间窗口并不充裕，这些都给转型过程带来了一定挑战。

2022年末ChatGPT面世后，出现越来越多的依赖于大语言模型（LLM）来增强SQL查询生成和调优过程的工具。大模型如ChatGPT、GPT-4、开源Llama3，已经展示了它们准确解释用户请求并生成精确SQL命令的能力。工商银行基于千亿大模型工银智涌的ChatBI，通过语义理解、数据配置等手段已具备端到端的数据分析能力。

基于前期在大模型NL2SQL应用方面积累的经验，结合在数据库SQL调优方面的特殊要求，工商银行打造了ChatSQL智能研发工具期望将大模型技术应用于数据库性能调优领域，以解决SQL查询的性能优化问题。 

ChatSQL智能研发工具面向数据库DBA用户，通过ChatSQL优化引擎模块，调度大模型、数据库交互代理、调优专家知识库、反馈评估等模块。ChatSQL 技术原理如图1所示。

一是ChatSQL优化引擎：统筹各个模块信息，数据与通用大模型进行交互并检查、评估SQL正确性。

二是数据库交互代理用于从数据库抽取SQL相关的数据，包括数据库表结构、执行计划、SQL正确性等。

三是调优专家知识库内容包含优化规则、数据库开发规范，经典优化案例。在优化过程中上述与SQL相关的知识库内容将一并发送至大模型供其上下文学习。

四是反馈评估模块负责用户交互，SQL检查，优化结果及效果评估反馈。

图1  ChatSQL 技术原理

ChatSQL智能研发工具的核心能力包括下面四个方面：

大模型拥有着卓越的语言理解和生成能力，实践发现当接收到SQL优化的提示时，大模型基本上会给出优化建议，但由于通用大模型对新兴数据库调优知识不足，存在有时优化方向不正确、优化结果不稳定和易产生幻觉的问题。

通过收集一定量调优知识语料库，对预训练大模型进行微调，不仅保持了大模型的原始训练知识，还能增加其在数据库SQL调优方面的能力。但由于基于现有通用大模型进行微调所需的训练语料不足，且GPU算力资源紧张，微调方法暂不可行。

上下文学习（ICL）是使用大模型的另一种主要方法，通过在任务描述提示中提供示例/演示来让大模型学习新任务，从而使得大模型能解决数学推理等复杂任务。ICL的关键思想是设计适当的提示策略，引导模型执行所需的任务。将ICL方法应用于SQL优化场景，能够在不进行显式重新训练的情况下让大模型适应SQL调优的任务，因此，我们采用上下文学习的方式赋能大模型，其中涉及到的上下文内容包括：SQL相关的数据库表结构、执行计划、从知识库中提炼的针对性调优案例等。不足之处在于，额外增加的上下文文本显著增加了提示词Token的长度，因而对大模型的能力有更高的要求。 

非多模态的大模型只能接收文本输入、产生文本输出，缺乏对现实世界的感知能力。大模型代理，也称智能体，是能够感知环境、做出决策和采取行动的人工实体。数据库交互代理是我们在ChatSQL中为大模型感知待优化的数据库而建设的智能体，相当于为大模型增加了间接感知/影响外部的触手。

根据目的，当前实现了两类代理，分别为感知类代理和执行类代理。其中：

感知代理用以获得表/视图的结构信息和索引信息，目前通过连接数据库实时获取，理论上也支持通过访问元数据管理信息系统的接口来访问相关结构信息。

执行代理通过执行Explain（执行计划）或Explain Analyze（生成执行计划并执行）来收集SQL语句执行计划和执行概要信息。对于人类数据库DBA而言，观察SQL的执行计划是非常重要的一个环节。以高斯数据库为例，高斯的SQL执行计划是一个节点树，显示数据库执行一条SQL语句时执行的详细步骤。每一个步骤为一个数据库运算符。EXPLAIN给每个执行节点都输出一行，显示基本的节点类型和优化器为执行这个节点预计的开销值。如下所示。 

 最底层节点是表扫描节点，它扫描表并返回原始数据行。不同的表访问模式有不同的扫描节点类型：顺序扫描、索引扫描等。如果查询需要连接、聚集、排序、或者对原始行做其它操作，那么就会在扫描节点之上添加其它节点。第一行（最上层节点）是执行计划总执行开销的预计。这个数值就是优化器试图最小化的数值。

有经验的数据库DBA依据执行计划信息来判断执行瓶颈并提出有针对性的优化建议。类似地，大模型以执行计划作为上下文之一部分，为准确提供优化建议提供了依据。并且在得到大模型改写的SQL之后，执行代理仍然需要了解其执行计划并进行对比，以确认改写SQL的性能提升情况。

为了防止SQL调优过程对数据库环境产生副作用，默认情况下，对于优化前后的SQL，执行代理既不执行SQL，也不执行Explain AnalyzeSQL的。这也符合一般的研发流程。 

SQL调优极度依赖于数据库DBA个人能力的一个主要制约就是调优经验的不足，或者说领域知识的差异。SQL调优专家知识库是通用大模型可以实现上下文学习的关键，同时也是ChatSQL工具的核心资产。此部分能力存在两个挑战：

（1）知识库的积累。ChatSQL的知识库来源包括数据库开发指南中的SQL调优章节、显式指定的优化规则、行内的数据库开发规范以及转型过程积累的经典优化案例。SQL调优专家知识库有基本统一的组成，包括规则名称、描述、适用数据库类型、适用版本、示例（优化前SQL、优化点、优化后SQL）等主要内容，以表格形式存储。当前已经积累了面向三个不同数据库类型、百余条优化知识。

（2）知识库的检索。中等复杂的SQL往往涉及多个表、多个join子句/子查询，以及复杂的where条件和Group by子句，还可能包括嵌套查询、连接操作和聚合函数等，长SQL语句的可读性通常也很差。由于大模型一次请求处理所支持的Token长度受限，把所有的调优知识连同SQL语句一次性给到大模型，既不经济，效果也很差。因此，通过对SQL（结合其元数据和执行计划）进行必要的预处理，根据预处理结果从知识库命中一条或少数几条调优知识，将是一个可行的方法。预处理方法主要包括三种：

一是执行计划统计，即对执行计划关键节点的成本代价（如运行时间、扫描行数等）进行统计，识别运行瓶颈。

二是逻辑语法树（AST）匹配，将SQL语句解析为逻辑语法树，根据预设规则对SQL语句结构与知识库进行匹配。例如，对于高斯数据库，对子查询的优化策略高度依赖子查询出现的位置，当子查询位于SELECT子句中时，优化知识是建议根据数据量情况用表关联方式改写，而当子查询位于FROM和WHERE子句中时则为其他优化建议。通过对SQL的精细解析，将最适合的优化策略提取出来并提示大模型，将能得到更有效的改写结果。

三是嵌套表分析，对于一些SQL中存在多层嵌套的结构（例如view，function）进行展开以供知识库匹配。

ChatSQL SQL关键技术如图2所示。

图2  ChatSQL SQL关键技术

大模型的成效评估包括人工评估和自动评估两种方法，一般涵盖多个维度，包括语义理解、知识推理、专业能力、应用能力、指令跟随、鲁棒性、偏见、幻觉和安全性等，这些维度可以帮助评估大模型在不同任务和领域中的表现和能力。NL2SQL、QA等场景已经有了为数众多的公开的评估数据集，也因而有了自动化的评估方法，可用于大模型间的横向比较。然而，SQL调优没有开放的数据集和现成的评估方法可用，因此现阶段采用人工评估方法来衡量其成效。

最终优化效果能否被认可，将取决于用户根据优化建议和各类提示信息进行综合人工判断后的“赞”和“踩”的评价反馈。

此外，SQL优化过程允许用户进行反馈和调整，作为对大模型优化的人工干预。同时，如果用户对优化建议有特定需求或发现潜在问题，可以通过反馈机制向系统提交意见，帮助持续改进优化策略。 

第一步：应数据库交互代理的需求，输入待优化ＳＱＬ的数据库环境连接信息，并尝试连接，如图3所示。

图3  数据库连接

第二步：输入待优化的SQL语句，如图4所示。

图4  SQL输入

第三步：借助数据库感知代理从数据库中获取表结构信息，通过数据库执行代理获取SQL执行计划信息（如图5、6所示）。有经验的用户可从此步骤了解当前SQL语句的性能瓶颈所在。

图５ 执行计划

图６表结构

调优专家知识库模块通过对上述数据的分析和匹配，找出影响查询性能的关键因素，并给出优化建议，供用户参考，如图7所示。

图7 知识库建议

第四步：根据与特定数据库适配的内置提示词模板，按照上下文学习的要求将结构信息、执行计划信息、待优化SQL语句和调优知识库组装发送给大模型，启动优化过程，静待反馈。优化结果如图8所示。

图８ 优化结果

第五步：调整和反馈。

在获取优化结果后，用户可以根据优化后执行计划情况，进行交互式调优。系统将重新获取优化后SQL的执行计划，以供用户和原执行计划进行对比和评估。此过程可反复迭代。 

ChatSQL已经在软件开发中心内部多个部门得到应用，并成功优化了百余条语句。其中比较典型的例子是在调优某大数据部门批量程序时，待优化SQL包含5层VIEW嵌套，关联多达10张表。经测试，此情况下ChatSQL仍可以提供有效建议。不过，通用大模型改写能力尚存在不足，难以将此SQL优化点全部改写正确。

通过行内的实践和评估，受限于当前大模型的能力，近期计划ChatSQL将主要针对表关联不超过五个、子查询嵌套不超过三层的SQL进行进一步提升优化。 

根据试点反馈和目前ChatSQL存在的不足，计划推广前在以下三个方面进行提升:

研发测试环境与生产环境由于数据规模等不同，会导致得到不同的执行计划，而这可能误导优化方向，最终由于不准确的优化建议导致成效不理想。通过构建工具链将生产环境的数据库统计信息同步至测试环境，保持两个环境执行计划生产依据一致，将有效提升工具整体调优过程的质量。

通过构建数据库调优决策树，有效提升优化规则检索命中率，减少不相干优化规则的干扰。同时，对多层嵌套的复杂SQL进行层次化调优，将复杂SQL分解成较小的可执行的语句，逐个优化，减少每次提交给大模型的代码量，降低token数的同时降低大模型错误率，如图9所示。

图9  利用决策树和层次化方法完善调优过程示意

一是检查优化前后SQL语义的等价性，实践中发现，虽然已经采取了很多提示约束，但对于非常复杂的sql语句，仍有可能生成优化后语义不等价的SQL，包括可能被忽略的返回列、不一样的where条件等，通过对SQL进行语法解析，分析关键的语义项，过滤不等价优化结果。二是调用执行代理生成优化后SQL语句的执行计划，并对比优化前的执行计划，观察资源消耗、数据读取量等关键指标以评估优化效果，筛除低效优化建议。通过两项措施，提升ChatSQL优化效果。  

-END-

前期精彩原创推荐（点击图片进入阅读）：