当前位置：首页 > news >正文

一条慢 SQL 的“会诊记录”：用 JiuwenSwarm 组织 SQL 优化 Swarm Team

news 2026/6/2 16:31:44

线上接口变慢时，最常见的一句话是：“是不是 SQL 没加索引？”
这句话有时对，有时很危险。慢查询背后可能是索引缺失，也可能是条件选择性差、统计信息失真、分页方式不对、函数阻断索引、JOIN 顺序异常，或者业务上返回的数据本来就太多。只凭经验拍一个索引，可能短期让查询快一点，也可能把写入拖慢，甚至让另一个查询变慢。

这一次我用 JiuwenSwarm的 Agent Swarm 做了一个偏工程排障的 Swarm Skill：sql-optimization-war-room-team。它不是用来“自动改数据库”的，而是把一次 SQL 优化拆成可审计的会诊流程：取证、读执行计划、索引建议、SQL 改写、风险检查、验证报告。

这篇文章会按一次慢查询值班记录来写。

一、先定规则：慢 SQL 不靠玄学优化

SQL 优化最怕跳过证据直接给方案。

我希望这支 Agent Swarm 遵守几条规则：

没有执行计划，不下确定结论。
没有表结构和已有索引，不随便建议新索引。
没有业务语义，不保证 SQL 改写等价。
没有压测或对比数据，不宣称优化成功。
涉及生产库 DDL/DML，必须人工审批。

这就是为什么我把它叫做war-room。不是因为它要制造紧张感，而是因为慢查询排障需要角色分工和证据链。

二、环境准备

打开https://www.openjiuwen.com/jiuwenswarm官网，我们可以看到在快速开始这里有，有2个平台的安装包可以进行下载，安装的过程也是非常的简单，只需要点击下一步即可完成安装，再打开应用即可。

启动后需要配置大语言模型（API Key、模型名称等），配置完成后点击对话测试，能正常回复就说明环境就绪了。

对话回复即为成功了。

三、TeamSkill Creator Prompt

闲言少叙，直接正题。

我们的本次的目的是实现一个 SQL 会诊团队，不是 “帮我优化 SQL” 这么简单，而是帮我打造一个真正的 SQL 专家级别的会诊团队。

根据之前我们定的规则，大概需要诊断、查询·、定位、排查、索引、改写等步骤。那么我就直接让其规划一下。

在开始前，还需要特别说明一下，我们需要使用到的官方的 teamskill-creator 用以创建我们自己的团队，该 skill 会根据需求，自动规划角色、步骤等。可以选择提前安装，也可以选择在对话中，JiuwenSwarm会自动帮我们安装。

执行前，我们只需要一句话就可以实现，不过，为了让其更加完善，我们加一点点限制，这个 Prompt 可以了。就像下面这样：

请创建一个 Swarm Skill：sql-optimization-war-room-team，面向后端开发和 DBA，协同分析慢查询、执行计划、索引建议、SQL 改写、风险评估和优化前后验证报告，设计一支 SQL 诊断团队，至少包含：问题指挥官、查询取证员、执行计划阅读员、索引架构师、SQL 改写专家、回归风险守门员、验证报告员。 要求： - 不能直接执行生产数据库 DDL、DML 或破坏性操作。 - 没有执行计划时，只能输出假设和补充证据清单。 - 索引建议必须说明收益、成本、字段顺序、冗余风险和回滚方式。 - SQL 改写必须说明语义是否等价。 - 最终输出为 Markdown 优化报告，包含证据、瓶颈、方案、风险、验证步骤和上线建议。

这段 Prompt 的重点是“证据”和“风险”。SQL 优化不是写一个看起来更短的查询，而是要证明它更安全、更快、更可回滚。

注意：要切换到集群模式，Cluster。

Team Leader 指挥官正在编排分析整个任务进程。

各个角色个司其职。

最终产物，每个角色都产出自己的分析：

.jiuwenswarm/.agent_teams/jiuwen_team_sess_19e2adaee4e_e334f8/team-workspace/artifacts ├── case_input.md ├── final_report.md ├── forensic_report.md ├── index_proposal.md ├── risk_assessment.md ├── sql_rewrite_proposal.md └── verification_report.md

四、团队角色概述

这支 Swarm Skill 一共包含了 7 个核心角色：

角色 ID	角色名称	核心职责
incident-commander	问题指挥官	确认数据库类型、版本、影响接口、目标耗时、优化约束（如是否允许加索引/改 SQL）。
query-profiler	查询取证员	整理 SQL、表结构、已有索引、数据量、慢日志、返回行数等原始证据。
execution-plan-reader	执行计划阅读员	深度解读 EXPLAIN/ANALYZE，识别扫描类型、连接顺序、临时表、排序和回表等瓶颈。
index-architect	索引架构师	设计索引方案，确定联合索引顺序，评估覆盖索引可能性及写入成本。
rewrite-specialist	SQL 改写专家	负责 SQL 逻辑优化，如处理函数阻断、优化分页、子查询改写并确保语义等价。
regression-guardian	回归风险守门员	风险评估，防止方案引入写入压力、锁表风险或语义变更。
validation-reporter	验证报告员	汇总优化前后指标、方案对比、验证步骤及上线建议，输出最终报告。

这个组合的关键不是角色多，而是职责不混。索引建议和 SQL 改写最好分别提出，再由风险守门员拦一遍。

五、来一场真正的优化吧

我设计了一个典型慢查询场景：

使用 sql-optimization-war-room-team 分析这条慢 SQL。 数据库：MySQL 8.0 业务：订单后台列表，按商户、状态、时间范围筛选，按创建时间倒序分页。 SQL： SELECT id, merchant_id, user_id, status, total_amount, created_at FROM orders WHERE merchant_id = 1024 AND status IN ('PAID', 'SHIPPED') AND DATE(created_at) >= '2026-05-01' ORDER BY created_at DESC LIMIT 20 OFFSET 10000; 表结构摘要： orders(id PK, merchant_id, user_id, status, total_amount, created_at, updated_at) 已有索引： PRIMARY(id) idx_created_at(created_at) idx_merchant_id(merchant_id) 数据量： orders 约 800 万行，merchant_id=1024 约 12 万行。 慢日志： 平均 3.8s，扫描行数较高。 请输出瓶颈判断、索引建议、SQL 改写建议、风险和验证步骤。

任务开始执行，Team leader 总指挥出山。

这个例子里，团队可能会给出几类判断：

DATE(created_at)会让索引利用变差，应改成范围条件。
OFFSET 10000深分页成本高，可以考虑基于游标的 seek pagination。
可能需要联合索引(merchant_id, status, created_at)，但字段顺序要结合选择性和排序验证。
如果使用覆盖索引，需要考虑 select 字段、索引长度和写入成本。
改写分页方式会影响前端交互，需要确认是否允许从页码分页改为游标分页。

注意，这里仍然不能直接说“已经优化成功”。没有真实 EXPLAIN ANALYZE 和压测数据时，最多只能说“建议验证”。

六、Agent Swarm 的价值：从“拍脑袋”到“生产流水线”

普通 AI 往往会直给一个“看起来正确”的答案，比如：

-- 普通 AI 可能直接给出的建议CREATEINDEXidx_orders_merchant_status_createdONorders(merchant_id,status,created_at);

但在真实的生产环境中，我们需要的不是一个“点子”，而是一条证据链。通过这张对比图，我们可以清晰地看到两者的本质区别：

维度	普通 AI (Prompt 模式)	Agent Swarm (Swarm Skill 模式)
思维深度	点状思维，直给结论。缺乏底层证据支撑，优化建议往往停留在“经验主义”层面。	系统思维，证据驱动。从取证、分析执行计划到方案生成，每一步都基于可审计的实时数据。
风险控制	盲目优化，缺乏闭环。不考虑索引带来的写入性能下降或锁表风险，属于“幸存者偏差”式优化。	对抗博弈，安全优先。引入“风险守门员”角色，专门寻找方案缺陷，确保上线过程可预测、可回滚。
工程复用	一次性指令，无法沉淀。优化质量极度依赖当下的 Prompt 质量，经验无法在组织内低成本流转。	资产沉淀，标准化流水线。将排障 SOP 固化为 Swarm Skill，实现复杂问题的自动化、标准化处理。

Coordination Engineering（协同工程）在这里体现为对“过程”的严密控制。它不再是让 AI 随意发挥，而是规定了谁负责事实（取证员）、谁负责假设（计划阅读员）、谁负责挑战方案（守门员）。

这种流程化的设计，让输出结果从“一句话建议”变成了“一份工程评审报告”，极大地降低了人为失误的概率。

七、生成后的文件结构

通过 Swarm Skill Creator，我们可以在指定目录下得到一套结构严密的技能包：

# 团队技能包存储路径.jiuwenswarm/agent/jiuwenswarm_workspace/skills/sql-optimization-war-room-team

其核心文件目录树如下：

sql-optimization-war-room-team/ ├── SKILL.md # 团队入口：定义角色 ID 与工作流概述 ├── workflow.md # 协作流程：包含 Mermaid 流程图与各阶段交付物要求 ├── bind.md # 行为约束：定义安全红线（如禁止执行 DDL） ├── dependencies.yaml # 环境依赖：声明需要的工具（sqlite3, python 等） └── roles/ # 角色定义目录 ├── incident-commander.md # 问题指挥官：定义边界与目标 ├── query-profiler.md # 查询取证员：收集原始证据 ├── execution-plan-reader.md # 计划阅读员：解读 EXPLAIN ├── index-architect.md # 索引架构师：设计索引方案 ├── rewrite-specialist.md # 改写专家：SQL 逻辑优化 ├── regression-guardian.md # 风险守门员：执行负面检查 └── validation-reporter.md # 验证报告员：汇总最终报告

其中我最看重的是bind.md。它明确禁止直接执行生产数据库操作，并要求没有执行计划时只输出假设。这一点对 SQL 优化尤其重要，因为数据库优化建议如果被误用，影响可能比原来的慢查询更大。

7.1 SKILL.md：入口文件

生成的 SKILL.md 包含完整的 frontmatter 和 body。frontmatter 定义了 7 个角色的id、purpose，body 部分有 Workflow 概述和 6 个阶段描述。

优点：

description 遵守了"WHAT / WHEN / NOT"三段式，清晰说明了触发场景和禁止行为
每个角色的purpose控制在一句话内，定位精准
Workflow 概述的 6 个阶段和 workflow.md 一致，没有出现跨文件矛盾

不足：

所有角色的skills: []和tools: []都是空的。Swarm Skill Creator 的 Stage 2 应该自动扫描本地可用技能和工具进行匹配，但实际没有匹配到任何东西。对 SQL 诊断场景来说，sqlite3、python3这些工具只出现在了dependencies.yaml里，没有关联到具体角色

7.2 角色文件：Persona 设计

这是最值得细看的部分。Swarm Skill Creator 规范要求每个角色文件包含 5 个必选章节：Identity、Success Criteria、Boundary、Output Schema、Inline Persona for Teammate。

我逐个检查后发现，实际生成的角色文件都只有 1 个章节：Inline Persona for Teammate，缺少了其他 4 个必选章节。

以下是 7 个角色的 Persona 内容和评价：

角色	Persona 核心指令	优点	缺陷
incident-commander	“先问清楚证据，不急着给方案”	明确了"先定义问题再行动"的指挥原则	缺少具体的输出模板（应该输出什么格式的问题清单？）
query-profiler	“像取证人员，只记录可验证事实和缺失证据，不提前下结论”	"取证人员"类比精准，角色边界很清晰	没有定义证据收集的标准清单模板
execution-plan-reader	“没有执行计划时只能给假设”	关键约束写进了 Persona 而不只是 bind.md，增强了执行力	没有说明不同数据库（MySQL vs PostgreSQL）的 EXPLAIN 差异处理方式
index-architect	“不要只说’加索引’，必须给出理由和风险”	直接阻断了最常见的低质量建议	缺少联合索引字段顺序的决策框架（按选择性排还是按查询条件排？）
rewrite-specialist	“所有改写都要说明是否语义等价”	语义等价要求是 SQL 改写的命门，写在 Persona 里是对的	没有要求提供改写前后的对比格式
regression-guardian	“阻止’看起来更快但线上更危险’的方案”	Motto 很好，对抗性角色定位清晰	缺少具体的风险检查清单（应该检查哪些维度？）
validation-reporter	“没有真实验证数据时，必须写’待验证’”	防止了 AI 最常见的"假装优化成功"问题	没有给出报告的 Markdown 模板

7.3 workflow.md：流程设计

workflow.md 包含一张 Mermaid flowchart 和两个关键章节：Required Evidence 和 Quality Gates。

优点：

流程图清晰展示了串行和并行关系：index-architect 和 rewrite-specialist 在 execution-plan-reader 之后并行执行，再统一由 regression-guardian 检查
Quality Gates 的 4 条规则都切中要害（无执行计划不下定论、索引要说明成本、改写要说明等价性、上线要有回滚方案）
Required Evidence 列出了 6 项必备证据，比很多手工 SOP 更完整

不足：

缺少Detailed Steps章节——按 TeamSkill Creator 规范，每个步骤应该有 executor / input / output / serial-or-parallel / quality gate 的详细说明
没有定义降级路径：如果用户只给了 SQL 没给执行计划，流程应该怎么变？目前只在 Quality Gates 里提了一句，没有在流程图中体现

7.4 bind.md：行为约束

bind.md 有 6 条规则。

优点：

"不直接执行生产数据库写操作"是最重要的安全红线，放在第一条，位置对
“对 MySQL、PostgreSQL、SQLite 等差异要显式说明”——这一条很多人会忽略，AI 很容易混用不同数据库的方言
“最终报告必须区分’可立即尝试’‘需要压测’‘不建议上线’”——三级分类非常实用

不足：

按 TeamSkill Creator 规范，bind.md 应该包含三个必选章节：Resource Constraints、Behavioral Constraints、Failure Handling。实际生成的只是一个扁平的规则列表，缺少结构化
没有定义max_parallel_teammates、total_token_budget等资源约束
没有定义 teammate 失败时的重试策略和降级方案

7.5 dependencies.yaml：依赖声明

列出了 3 个可选工具：sqlite3、python3、diff。

优点：

全部标记为required: false，不会因为缺少工具导致团队无法运行
degradation 章节说明了降级策略：“缺少数据库工具时，仅基于用户提供的证据分析”

不足：

external_skills: []为空——SQL 诊断场景其实可以关联 web-research 技能来查询数据库文档、版本变更日志等
工具没有关联到具体角色（比如 sqlite3 应该关联给 query-profiler 或 execution-plan-reader）

7.6 综合评价

维度	评分（5 分制）	说明
角色分工	⭐⭐⭐⭐⭐	7 个角色定位精准，职责不重叠，证据链完整
流程设计	⭐⭐⭐⭐	串并行关系合理，Quality Gates 实用，但缺少降级路径和 Detailed Steps
角色 Persona	⭐⭐⭐	Motto 和核心指令质量高，但缺少 Identity/Success Criteria/Boundary/Output Schema 4 个必选章节
行为约束	⭐⭐⭐⭐	安全红线和区分度到位，但结构不符合规范（缺少三段式）
依赖配置	⭐⭐⭐	降级策略有，但工具未关联角色，社区技能未扫描
规范合规	⭐⭐	能跑起来，但距离 TeamSkill Creator 自己定义的规范有明显差距

一句话总结：TeamSkill Creator 生成的sql-optimization-war-room-team在架构设计层面（角色分工、流程拓扑、安全约束）质量很高，但在文件规范层面（角色章节完整性、bind 结构化、依赖-角色关联）存在明显缺失。它更像一个"高质量的草稿"而不是"可直接发布的成品"——需要人工补充 Output Schema、Boundary、降级路径等细节后才能进入生产使用。

八、最终报告：final-optimization-report.md

一份完整的“会诊报告”应该包含从证据到执行的全链路信息。以下是从本次实战生成的final-optimization-report.md中提取的精华部分，展示了 Agent Swarm 是如何通过数据驱动决策的：

8.1 核心性能指标（预期）

阶段	方案组合	预估耗时	扫描行数	提升幅度
基线	原始查询	~3.8s	~120,000	-
Phase 1	覆盖索引 + DATE 消除	~1.0-1.5s	~30,000	↓ 60-75%
Phase 2	Phase 1 + 游标分页	~0.3-0.6s	~20	↓ 85-92%

8.2 瓶颈深度诊断

来源：execution-plan-reader推演分析

头号元凶 (Primary)：DATE(created_at)函数包裹导致索引失效，无法进行范围扫描。
次要元凶 (Secondary)：深分页OFFSET 10000导致 99.8% 的扫描数据被丢弃，产生大量无效 IO。
结构缺陷 (Design)：现有索引均为单列，无法支撑多条件组合过滤，导致 12 万行数据回表。

8.3 优化方案 Verdict (决策矩阵)

来源：regression-risk-gatekeeper风险评估

✅GO (覆盖索引 B)：风险评分 5.7 (Low-Med)。建议低峰期执行 Online DDL，通过“以空间换时间”消除回表。
✅GO (DATE 改写)：风险评分 4.0 (Low)。零风险，建议立即配合索引上线。
⚠️CONDITIONAL GO (游标分页)：风险评分 7.6 (Medium)。虽然性能提升最显著，但需前端配合取消“跳页”功能，并由开发改造 API 逻辑。