D-Bot： 来自的清华大学数字运维员工研究，LLM 担任数据库管理员
作者：袖梨
2026-07-29
TLDR• 打造数字运维员工，并考察 LLM 胜任数据库管理员的潜力，是清华大学研发 D-Bot 的探索方向；这个数据库诊断系统以大型语言模型 (LLM) 为基础。• 数据库发生异常后，D-Bot 会结合工具、树搜索算法和从诊断文档提取的知识展开诊断；用户反馈还能用于继续改善结果。• 面对复杂异常，D-Bot 通过多 LLM 协作机制加以解决，并生成内容详尽的诊断报告，支持用户在线查看诊断结果及完整过程。• 实验结果显示，D-Bot 的表现优于传统数据库诊断方法，甚至能够媲美人类专家；该系统已经开源，便于用户部署使用。引言作为信息时代的基石，数据库在各行各业承担着至关重要的作用。然而，数据库系统日趋复杂，如何诊断并解决性能异常，已成为数据库管理员 (DBA) 面临的重要挑战。无论依赖专家规则还是机器学习模型，传统数据库诊断方法都受限于场景理解不足、泛化能力有限和推理能力欠缺，难以适应持续增长的数据库管理需求。设想电商平台开展促销活动时，数据库突然出现性能瓶颈，订单处理随之变慢，用户体验下降，平台损失的不只是订单，还有用户信任和品牌声誉。传统诊断方法通常要求 DBA 排查数小时甚至数天，才能发现问题根源；许多问题还成因复杂，牵涉多个数据库组件与配置参数，仅依靠 DBA 的经验和有限工具，很难迅速定位并有效优化。人工智能领域近年来出现革命性变化，背后的推动力之一是大型语言模型 (LLM) 所展现的代码生成、问题解决及自然语言理解能力。数据库诊断由此获得了新的工具和观察视角：引入 LLM 有望打破传统方法的瓶颈，让诊断与优化趋向自动化、高效和精准，进而为数据库管理难题提供新解法，开启数据库自治的新时代。LLM as Database Administrator：D-Bot 系统概述 数字运维员工D-Bot 是由清华大学数据库团队开发的一款基于 LLM 的数据库诊断系统，旨在利用 LLM 的强大能力，自动诊断数据库异常，并提供可行的优化建议，探索 LLM 作为数据库管理员的潜力，打造数字运维员工，为数据库管理带来革命性的变革。D-Bot 的设计理念是将 DBA 的经验和知识编码到 LLM 中，并结合数据库诊断工具和技术，实现自动化的数据库诊断和优化。D-Bot 的目标是成为 DBA 的得力助手，帮助 DBA 从繁琐的诊断工作中解脱出来，专注于更高级的数据库管理任务。D-Bot 的核心优势以下是 D-Bot 区别于传统数据库诊断方法的优势:• 精准诊断: 借助丰富知识库与强大推理能力，D-Bot 可以深入理解数据库异常的上下文，准确判断异常根本原因，减少误诊和漏诊。它如同经验丰富的“老中医”，通过“望闻问切”直达问题根源。• 节省时间和成本: 大部分诊断工作可由 D-Bot 自动完成，由此显著降低 DBA 的工作量，节约时间与成本。DBA 因而可以把更多精力投入数据库架构设计、性能调优等等复杂任务；D-Bot 就像得力助手，帮助 DBA 摆脱烦琐的诊断工作。• 高度泛化: D-Bot 可以持续学习新知识与新经验，并随数据库环境变化自我调整，因此具有较强的泛化能力，能够处理各种类型的数据库异常。如同一位“全科医生”，它可以应对数据库中的各类“疑难杂症”。D-Bot 的架构和工作流程下图展示了 D-Bot 的架构，主要由以下几个模块构成:图：D-Bot 架构图• 异常监控: 数据库的 CPU 使用率、内存使用率、磁盘 I/O 延迟等等指标会受到实时监控；发现异常模式或某项指标超过预设阈值后，系统随即告警，再把相关信息交由 D-Bot 诊断。• 异常描述生成: 为给后续 LLM 诊断准备上下文，需要把历史运行日志、数据库配置信息、告警信息等整理成结构化的异常描述。经验丰富的医生问诊时详细了解相关检查结果、症状和病史，与这一过程相似。• 数据库诊断: 识别数据库异常的根本原因并提出具体优化建议，需要多个 LLM 专家共同完成，这构成 D-Bot 的核心模块。它类似一个集思广益的专家会诊团队，最终目标是确定最佳治疗方案。• 报告生成: 系统会依据诊断结果自动形成详细报告，其中包含异常描述、根本原因分析、优化建议和诊断过程等，便于 DBA 排查处理。如同一份完整病例报告，既记录诊断过程，也记录治疗方案。D-Bot 核心模块详解离线知识提取构建一个 comprehensive 的知识库，是 D-Bot 赋予 LLM 数据库诊断能力的第一步：结构化知识将从专家经验、案例库及大量数据库诊断文档中提取。整个过程如同一位“学霸”先学习大量医学文献和书籍，再开始诊断。文档中的解决方案、排查步骤、影响范围、症状描述、异常类型等关键信息，会由 D-Bot 借助基于信息抽取和语义分析的方法自动识别，再转成可供 LLM 理解与使用的结构化知识。其作用好比一位“阅读达人”，能迅速抓取文章的关键信息和中心思想。以 “死锁” 为例，其解决方法、检测方法、原因、定义等等知识，都能由 D-Bot 从 PostgreSQL 官方文档获取。D-Bot 随后会把这些内容处理为结构化数据，存入知识库。提取完成的知识块主要由以下几个部分组成：
• 名称: 如 "慢查询优化"、"CPU 资源竞争" 等文字，是对知识块的简短描述；它承担着书名般的作用，用来概括一本书的主要内容。• 内容: 知识块会得到详细解释，如 "CPU 资源竞争是指多个数据库操作同时竞争 CPU 资源，导致系统性能下降"。这种解释承担书籍摘要的作用，即简要概括书本内容。• 指标: 如 "磁盘 I/O 延迟"、"CPU 使用率" 等，是知识块所关联的数据库性能指标；它们发挥书籍关键词般的作用，便于读者迅速定位相关知识。• 步骤: 诊断如何使用该知识块，会以具体步骤说明，例如 "首先检查 CPU 使用率，如果 CPU 使用率过高，则需要进一步分析是哪些进程占用了 CPU 资源"。它类似书籍目录，负责指引读者的阅读顺序。为便于 LLM 检索和使用，D-Bot 按照语义信息对已提取的知识块进行聚类，形成层次化知识图谱。例如，可以把与 "CPU" 有关的知识块归为一个类别，把与 "内存" 有关的知识块归为另一个类别，再按照具体异常类型细分每个类别。这如同图书馆按类别与主题整理书籍，方便读者查找。D-Bot 针对实际数据库文档完成知识块提取后，其聚类结果见下图：图6：D-Bot 知识库聚类结果工具准备性能监控工具、日志分析工具、SQL 优化工具等等丰富的数据库诊断工具，也被 D-Bot 纳入系统，而不只有知识库。借助它们，LLM 能获得更详尽的信息并深入分析，从而提高数据库异常诊断的准确度；这与经验丰富的医生使用各种医疗设备辅助诊断相似。D-Bot 为每一种工具准备了详细说明，内容涉及工具功能、参数、输入输出及使用示例等等。这些信息能够通过 API 提供给 LLM，LLM 再按需调用对应 API 获取信息，如同熟练的操作员可以熟练操控各种仪器设备。以数据库慢查询日志为例，LLM 可把日志文件传入 D-Bot 慢查询分析工具的 API，再取得执行时间、锁等待时间、慢查询的 SQL 语句等等结果，用于分析。诊断提示生成异常信息、数据库配置信息、历史运行日志等内容，会在数据库发生异常时被 D-Bot 汇总，自动形成用于引导 LLM 的诊断提示。其中涵盖历史诊断记录、可用工具、相关知识、异常描述等等 LLM 所需的全部信息。这类似经验丰富的老师面对学生的难题时先给出提示，再引导学生思考。两个关键问题决定 D-Bot 能否形成有效的诊断提示：• 知识检索: 如同到图书馆查找相关书籍，当前异常所对应的知识块需要从知识库中检索。为快速、准确锁定最相关的内容，D-Bot 使用结合语义相似度计算与关键词匹配的知识检索方法。比如出现 “CPU 使用率过高” 的数据库异常后，与 “CPU 资源竞争” 有关的知识块便会被 D-Bot 找出。• 工具匹配: 为了让 LLM 获取更多信息，需要像从工具箱挑选工具一样，在工具库中作出合适选择。D-Bot 的工具匹配方法结合机器学习模型和规则匹配，可综合数据库环境、症状描述、异常类型等信息自动确定最合适的工具。比如数据库出现 “慢查询” 异常，慢查询分析工具便会被 D-Bot 选中，用来协助 LLM 判断原因。基于树搜索的 LLM 诊断传统 LLM 通常采用链式推理，即依据上一步输出依次形成下一步输入，直至生成最终答案。不过，链式推理容易产生错误累积和推理路径偏差，特别是在复杂问题中，可能陷入局部最优解，使诊断结果失准。如同身处迷宫却只沿一条路前进，很可能走入死胡同。为突破链式推理的限制，D-Bot 采用基于树搜索的 LLM 诊断方法，把诊断视为在搜索树中寻找最优解：每个节点对应一个诊断步骤，每个分支对应一种可能方向。D-Bot 借助 LLM 推理能力评估各分支收益，选择收益最大的分支扩展，直至找到最优诊断路径。如同每次都选择最有可能通往出口的道路，最终走出迷宫。基于树搜索的 LLM 诊断流程：D-Bot，图7例如，当数据库出现 “CPU 使用率过高” 的异常时，D-Bot 会构建一个搜索树，根节点是 “CPU 使用率过高”，然后根据知识库和工具库，生成多个分支，例如 “检查 CPU 资源竞争”、“检查慢查询”、“检查数据库配置” 等等。D-Bot 会利用 LLM 评估每个分支的收益，并选择收益最大的分支进行扩展。如果选择了 “检查 CPU 资源竞争” 这个分支，那么 D-Bot 会进一步生成多个子分支，例如 “检查哪些进程占用了 CPU 资源”、“检查数据库连接数是否过高” 等等。D-Bot 会继续评估每个子分支的收益，并选择收益最大的子分支进行扩展，直到找到最优的诊断路径。D-Bot 为提升树搜索效率，进一步加入的优化策略如下，例如：• 剪枝策略: 对明显不可行的分支直接剪枝，以免浪费计算资源。这如同在迷宫中发现某条道路明显不通后立即放弃，从而避免浪费时间。• 缓存机制: 对于已经搜索的部分节点，系统会缓存相应结果，下次搜索直接调用，以免重复计算。如同探索过迷宫中的某个区域后记录地图，下次便无须再次探索。• 回溯机制: 搜索到某个节点并发现当前路径不可行时，系统会回到上一节点，改选其他分支继续搜索。如同在迷宫中走错道路后退回上一个岔路口，再选择另一条路。多 LLM 协作诊断机制对于一些复杂的数据库异常，单一的 LLM 专家可能难以胜任，需要多个 LLM 专家协作诊断，才能更准确地识别异常原因，并给出更有效的解决方案，就像是在医学领域，对于一些疑难杂症，往往需要多个科室的专家会诊，才能做出准确的诊断。D-Bot 通过多 LLM 协作诊断机制组织不同 LLM 专家协同工作，共同处理复杂问题。各位 LLM 专家拥有不同专长，包括 CPU 专家、内存专家、I/O 专家等等。数据库发生异常时，D-Bot 会按照异常类型和症状描述，自动选择合适的 LLM 专家团队，如同经验丰富的医生根据病人病情安排相关专家会诊。图：D-Bot 多 LLM 协作诊断流程各个 LLM 专家在诊断中并行执行任务，并以共享信息、彼此协作的方式完成诊断。具体而言，磁盘 I/O 延迟和网络吞吐量等指标交给 I/O 专家分析，缓存命中率和内存使用率等由内存专家分析，运行队列长度和 CPU 使用率等则由 CPU 专家分析。协作让每位专家掌握的信息更全面，也使异常原因的判断更准确；这如同专家会诊，大家先分享意见并讨论，再形成一致的诊断结果。演示效果网页端演示D-Bot 配备网页端界面，便于用户进行交互式诊断。通过这一界面，用户能够导入文档、创建知识库、开展对话问答并诊断数据库异常。• 用户可在 D-Bot 网页端完成数据库异常诊断、问答、知识库构建和文档上传；该界面的配置方式与前端均采用 Chatchat 项目方案。• D-Bot 同时提供用户反馈功能。用户可反馈诊断结果，如确认结果是否正确、是否需要继续分析等等。D-Bot 会依据反馈进行调整，包括重新诊断、修改诊断结果等等，以此增强诊断的准确性与可解释性。LLM 作为数据库管理员：未来展望D-Bot 带来了一条全新的数据库诊断路径，也让数据库自治的未来更具希望。未来，团队将继续对 D-Bot 进行优化，并发掘更多 LLM 应用场景，进一步推动数据库自治向前发展。
• 名称: 如 "慢查询优化"、"CPU 资源竞争" 等文字，是对知识块的简短描述；它承担着书名般的作用，用来概括一本书的主要内容。• 内容: 知识块会得到详细解释，如 "CPU 资源竞争是指多个数据库操作同时竞争 CPU 资源，导致系统性能下降"。这种解释承担书籍摘要的作用，即简要概括书本内容。• 指标: 如 "磁盘 I/O 延迟"、"CPU 使用率" 等，是知识块所关联的数据库性能指标；它们发挥书籍关键词般的作用，便于读者迅速定位相关知识。• 步骤: 诊断如何使用该知识块，会以具体步骤说明，例如 "首先检查 CPU 使用率，如果 CPU 使用率过高，则需要进一步分析是哪些进程占用了 CPU 资源"。它类似书籍目录，负责指引读者的阅读顺序。为便于 LLM 检索和使用，D-Bot 按照语义信息对已提取的知识块进行聚类，形成层次化知识图谱。例如，可以把与 "CPU" 有关的知识块归为一个类别，把与 "内存" 有关的知识块归为另一个类别，再按照具体异常类型细分每个类别。这如同图书馆按类别与主题整理书籍，方便读者查找。D-Bot 针对实际数据库文档完成知识块提取后，其聚类结果见下图：图6：D-Bot 知识库聚类结果工具准备性能监控工具、日志分析工具、SQL 优化工具等等丰富的数据库诊断工具，也被 D-Bot 纳入系统，而不只有知识库。借助它们，LLM 能获得更详尽的信息并深入分析，从而提高数据库异常诊断的准确度；这与经验丰富的医生使用各种医疗设备辅助诊断相似。D-Bot 为每一种工具准备了详细说明，内容涉及工具功能、参数、输入输出及使用示例等等。这些信息能够通过 API 提供给 LLM，LLM 再按需调用对应 API 获取信息，如同熟练的操作员可以熟练操控各种仪器设备。以数据库慢查询日志为例，LLM 可把日志文件传入 D-Bot 慢查询分析工具的 API，再取得执行时间、锁等待时间、慢查询的 SQL 语句等等结果，用于分析。诊断提示生成异常信息、数据库配置信息、历史运行日志等内容，会在数据库发生异常时被 D-Bot 汇总，自动形成用于引导 LLM 的诊断提示。其中涵盖历史诊断记录、可用工具、相关知识、异常描述等等 LLM 所需的全部信息。这类似经验丰富的老师面对学生的难题时先给出提示，再引导学生思考。两个关键问题决定 D-Bot 能否形成有效的诊断提示：• 知识检索: 如同到图书馆查找相关书籍，当前异常所对应的知识块需要从知识库中检索。为快速、准确锁定最相关的内容，D-Bot 使用结合语义相似度计算与关键词匹配的知识检索方法。比如出现 “CPU 使用率过高” 的数据库异常后，与 “CPU 资源竞争” 有关的知识块便会被 D-Bot 找出。• 工具匹配: 为了让 LLM 获取更多信息，需要像从工具箱挑选工具一样，在工具库中作出合适选择。D-Bot 的工具匹配方法结合机器学习模型和规则匹配，可综合数据库环境、症状描述、异常类型等信息自动确定最合适的工具。比如数据库出现 “慢查询” 异常，慢查询分析工具便会被 D-Bot 选中，用来协助 LLM 判断原因。基于树搜索的 LLM 诊断传统 LLM 通常采用链式推理，即依据上一步输出依次形成下一步输入，直至生成最终答案。不过，链式推理容易产生错误累积和推理路径偏差，特别是在复杂问题中，可能陷入局部最优解，使诊断结果失准。如同身处迷宫却只沿一条路前进，很可能走入死胡同。为突破链式推理的限制，D-Bot 采用基于树搜索的 LLM 诊断方法，把诊断视为在搜索树中寻找最优解：每个节点对应一个诊断步骤，每个分支对应一种可能方向。D-Bot 借助 LLM 推理能力评估各分支收益，选择收益最大的分支扩展，直至找到最优诊断路径。如同每次都选择最有可能通往出口的道路，最终走出迷宫。基于树搜索的 LLM 诊断流程：D-Bot，图7例如，当数据库出现 “CPU 使用率过高” 的异常时，D-Bot 会构建一个搜索树，根节点是 “CPU 使用率过高”，然后根据知识库和工具库，生成多个分支，例如 “检查 CPU 资源竞争”、“检查慢查询”、“检查数据库配置” 等等。D-Bot 会利用 LLM 评估每个分支的收益，并选择收益最大的分支进行扩展。如果选择了 “检查 CPU 资源竞争” 这个分支，那么 D-Bot 会进一步生成多个子分支，例如 “检查哪些进程占用了 CPU 资源”、“检查数据库连接数是否过高” 等等。D-Bot 会继续评估每个子分支的收益，并选择收益最大的子分支进行扩展，直到找到最优的诊断路径。D-Bot 为提升树搜索效率，进一步加入的优化策略如下，例如：• 剪枝策略: 对明显不可行的分支直接剪枝，以免浪费计算资源。这如同在迷宫中发现某条道路明显不通后立即放弃，从而避免浪费时间。• 缓存机制: 对于已经搜索的部分节点，系统会缓存相应结果，下次搜索直接调用，以免重复计算。如同探索过迷宫中的某个区域后记录地图，下次便无须再次探索。• 回溯机制: 搜索到某个节点并发现当前路径不可行时，系统会回到上一节点，改选其他分支继续搜索。如同在迷宫中走错道路后退回上一个岔路口，再选择另一条路。多 LLM 协作诊断机制对于一些复杂的数据库异常，单一的 LLM 专家可能难以胜任，需要多个 LLM 专家协作诊断，才能更准确地识别异常原因，并给出更有效的解决方案，就像是在医学领域，对于一些疑难杂症，往往需要多个科室的专家会诊，才能做出准确的诊断。D-Bot 通过多 LLM 协作诊断机制组织不同 LLM 专家协同工作，共同处理复杂问题。各位 LLM 专家拥有不同专长，包括 CPU 专家、内存专家、I/O 专家等等。数据库发生异常时，D-Bot 会按照异常类型和症状描述，自动选择合适的 LLM 专家团队，如同经验丰富的医生根据病人病情安排相关专家会诊。图：D-Bot 多 LLM 协作诊断流程各个 LLM 专家在诊断中并行执行任务，并以共享信息、彼此协作的方式完成诊断。具体而言，磁盘 I/O 延迟和网络吞吐量等指标交给 I/O 专家分析，缓存命中率和内存使用率等由内存专家分析，运行队列长度和 CPU 使用率等则由 CPU 专家分析。协作让每位专家掌握的信息更全面，也使异常原因的判断更准确；这如同专家会诊，大家先分享意见并讨论，再形成一致的诊断结果。演示效果网页端演示D-Bot 配备网页端界面，便于用户进行交互式诊断。通过这一界面，用户能够导入文档、创建知识库、开展对话问答并诊断数据库异常。• 用户可在 D-Bot 网页端完成数据库异常诊断、问答、知识库构建和文档上传；该界面的配置方式与前端均采用 Chatchat 项目方案。• D-Bot 同时提供用户反馈功能。用户可反馈诊断结果，如确认结果是否正确、是否需要继续分析等等。D-Bot 会依据反馈进行调整，包括重新诊断、修改诊断结果等等，以此增强诊断的准确性与可解释性。LLM 作为数据库管理员：未来展望D-Bot 带来了一条全新的数据库诊断路径，也让数据库自治的未来更具希望。未来，团队将继续对 D-Bot 进行优化，并发掘更多 LLM 应用场景，进一步推动数据库自治向前发展。
