数据库慢查询自动修复AI 辅助分析 Explain 执行计划并生成索引在后端服务的性能排障中数据库慢查询Slow Query是引发 CPU 飙升、连接池打满和服务级联雪崩的头号诱因。当 DBA 或监控系统抓到一条耗时超过 3 秒的高危 SQL 时传统的排查流程往往非常依赖资深工程师的个人经验人工登录 MySQL 控制台执行EXPLAIN或EXPLAIN ANALYZE逐行解读庞大的执行计划表格扫描行数 rows、访问类型 type、额外信息 Extra判断是发生了全表扫描ALL、索引失效隐式类型转换/函数操作列、还是临时表文件排序Using temporary; Using filesort手动设计最左前缀匹配的复合索引并在测试环境评估索引体积与写入开销。这一套分析流程对于普通开发人员门槛较高且耗时费力。结合数据库内置的执行计划分析器与大语言模型我们构建了一套自动化慢查询诊断与索引建议机器人。它能在捕获到慢查询的 3 秒内自动完成执行计划解析、定位失效根因并生成生产级、带向后兼容性的索引创建 DDL。自动化慢查询自愈流水线架构graph LR A[MySQL 慢查询日志流 / Prometheus 告警] -- B[诊断服务自动拉取对应表的 Schema 结构] B -- C[在影子从库执行 EXPLAIN FORMATJSON] C -- D[LLM 数据库性能优化专家 Agent] D -- E[输出精准根因 索引 DDL 风险提示回贴]核心实现结构化上下文抽取与 Prompt 构造单给大模型一条孤立的 SQL 语句很容易产生误导必须同时提供三部分关键上下文原始 SQL、当前建表 DDL、以及 JSON 格式的执行计划。import json from pydantic import BaseModel, Field from typing import List class SlowQueryDiagnosis(BaseModel): root_cause: str Field(description慢查询核心根因分析如未命中索引、隐式转换等) scanned_vs_returned_ratio: float Field(description扫描行数与返回行数比例) recommended_ddl: List[str] Field(description推荐的索引创建或修改 DDL 语句) sql_rewrite_suggestion: str Field(descriptionSQL 语句本身的重写优化建议) risk_assessment: str Field(description创建该索引对写入性能和磁盘体积的影响评估) def analyze_slow_query(sql: str, create_table_ddl: str, explain_json: dict, client) - SlowQueryDiagnosis: prompt f你是一位拥有十年经验的 MySQL 数据库性能优化专家DBA。请分析如下慢查询并给出最优修复方案。 【原始慢查询 SQL】 sql {sql}【数据表结构 DDL】{create_table_ddl}【MySQL EXPLAIN 执行计划 (JSON 格式)】{json.dumps(explain_json, indent2)}【诊断要求】严密分析执行计划中的 type、key、rows 以及 Extra 信息遵循最左前缀匹配原则与覆盖索引Covering Index优化思路严格禁止创建重复索引或冗余前缀索引必须输出安全的并发创建索引语法如 pt-online-schema-change 或 gh-ost 建议。response client.beta.chat.completions.parse(modelgpt-4o,messages[{role: user, content: prompt}],response_formatSlowQueryDiagnosis,temperature0.1)return response.parsed## 真实案例实测对比 ### 线上慢查询案例 查询近 7 天某个商户下特定状态的订单列表并按创建时间倒序分页 sql SELECT id, order_sn, total_cents, status, created_at FROM t_orders WHERE merchant_id M10023 AND status IN (PAID, SHIPPED) AND created_at 2026-09-01 00:00:00 ORDER BY created_at DESC LIMIT 20 OFFSET 0;原始表索引现状仅有单列索引idx_merchant_id (merchant_id)。MySQL EXPLAIN 结果分析type: refrows: 450,000扫描了该商户过去所有的 45 万行数据Extra: Using index condition; Using filesort在内存/磁盘中进行了全量文件排序。AI 输出的专业诊断报告与精准 DDL大模型给出的分析直击要害 【慢查询根因】 当前查询仅能利用 idx_merchant_id 过滤商户随后需要在 45 万行数据中逐行过滤 status 和 created_at并且由于索引未能覆盖排序字段触发了高开销的 filesort 磁盘文件排序。 【推荐复合索引方案】 根据等值列在前、范围列与排序在后的原则 sql -- 推荐最左前缀复合索引 ALTER TABLE t_orders ADD INDEX idx_merchant_status_created (merchant_id, status, created_at, total_cents, order_sn); 【重写与进阶优化建议】若字段较多无法建立全覆盖索引推荐建立核心索引idx_merchant_created_status (merchant_id, created_at, status)利用索引直接消除 filesort。⚠️ 【生产变更风险】当前表数据量超过 1000 万行禁止在业务高峰期直接执行ALTER TABLE推荐使用gh-ost进行无锁在线 DDL 变更。## 总结 将数据库深层内核知识固化为自动化分析 Agent让普通的业务开发人员也能在几十秒内获得媲美资深 DBA 的调优指导从源头上将慢查询风险拦截在生产爆发之前。