企业官网建设流程全解析

数据库慢查询自动修复：AI 辅助分析 Explain 执行计划并生成索引

在后端服务的性能排障中，数据库慢查询（Slow Query）是引发 CPU 飙升、连接池打满和服务级联雪崩的头号诱因。

当 DBA 或监控系统抓到一条耗时超过 3 秒的高危 SQL 时，传统的排查流程往往非常依赖资深工程师的个人经验：

1. 人工登录 MySQL 控制台执行EXPLAIN或EXPLAIN ANALYZE；
2. 逐行解读庞大的执行计划表格（扫描行数 rows、访问类型 type、额外信息 Extra）；
3. 判断是发生了全表扫描（ALL）、索引失效（隐式类型转换/函数操作列）、还是临时表文件排序（Using temporary; Using filesort）；
4. 手动设计最左前缀匹配的复合索引，并在测试环境评估索引体积与写入开销。

这一套分析流程对于普通开发人员门槛较高，且耗时费力。

结合数据库内置的执行计划分析器与大语言模型，我们构建了一套自动化慢查询诊断与索引建议机器人。它能在捕获到慢查询的 3 秒内，自动完成执行计划解析、定位失效根因，并生成生产级、带向后兼容性的索引创建 DDL。

自动化慢查询自愈流水线架构

graph LR A[MySQL 慢查询日志流 / Prometheus 告警] --> B[诊断服务自动拉取对应表的 Schema 结构] B --> C[在影子从库执行 EXPLAIN FORMAT=JSON] 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(description="SQL 语句本身的重写优化建议") 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, indent=2)}

【诊断要求】：

1. 严密分析执行计划中的 type、key、rows 以及 Extra 信息；

2. 遵循最左前缀匹配原则与覆盖索引（Covering Index）优化思路；

3. 严格禁止创建重复索引或冗余前缀索引；

4. 必须输出安全的并发创建索引语法（如 pt-online-schema-change 或 gh-ost 建议）。
   """

   response = client.beta.chat.completions.parse(
   model="gpt-4o",
   messages=[{"role": "user", "content": prompt}],
   response_format=SlowQueryDiagnosis,
   temperature=0.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: ref，rows: 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 的调优指导，从源头上将慢查询风险拦截在生产爆发之前。