如何让Kimi分析SQL执行缓慢的原因_采用优化逻辑Prompt
Kimi需基于提供的执行计划、表结构、字段基数、数据库版本及负载特征，按四步归因框架分析SQL变慢根源：先查计划跳跃，再定位最重节点，接着判断缓冲区异常，最后验证系统干扰，并每步给出可验证依据。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你想让Kimi精准定位SQL执行慢的根源，而不是泛泛而谈“加索引”或“改写SQL”，必须用结构化Prompt引导它聚焦执行计划、数据分布、锁等待等真实瓶颈点。
明确告诉Kimi分析边界与输入格式
在提问开头就限定分析范围：只基于你提供的执行计划（EXPLAIN ANALYZE输出）、表结构（CREATE TABLE语句）、关键字段基数（如WHERE条件列的distinct值占比）、当前数据库版本（如PostgreSQL 15.4）和实时负载特征（如是否有长事务阻塞）。
输入必须是纯文本块，不要截图、不要PDF、不要省略cost/actual time/rows等关键字段——【缺失actual time行将导致Kimi无法判断真实耗时分布】。
直接粘贴如下模板内容：
Kimi Claw
Kimi帮你一键部署的OpenClaw
【执行计划】
EXPLAIN (ANALYZE, BUFFERS) SELECT ...
→ 输出完整文本，含“Planning Time”“Execution Time”“Buffers:”等行
【表结构】
CREATE TABLE orders (id SERIAL, status TEXT, created_at TIMESTAMPTZ, ...);
【字段基数】
status列distinct值共5个，总行数1200万，'pending'占比82%；created_at近30天数据占91%。
【数据库环境】
PostgreSQL 15.4，shared_buffers = 4GB，work_mem = 64MB。
【当前异常现象】
该SQL平时200ms，今早突增至8.2秒，pg_stat_activity显示无锁等待，但pg_stat_bgwriter中checkpoints_timed频繁。
强制Kimi分层归因，禁用模糊归类
在Prompt中嵌入归因框架指令，让它按固定顺序排查：
- 第一步：检查执行计划是否发生计划跳跃（Plan Change）——对比历史快执行计划，确认是否因统计信息过期、绑定变量窥探失效或JOIN顺序突变导致走错索引；
- 第二步：定位最重节点（Highest Actual Total Time），若为Seq Scan且rows远大于expected，立即检查是否missing index或WHERE条件未命中索引；
- 第三步：若出现Shared Hit/Read Buffers异常高（如Read > 500MB），结合work_mem判断是否因排序/哈希溢出至磁盘；
- 第四步：验证是否受系统级干扰——checkpoints_timed频繁会触发fsync风暴，此时即使SQL本身无问题，IO也会被拖慢。
要求Kimi对每一层结论给出可验证依据，例如不能只说“建议建索引”，而必须写明：“应在orders(status, created_at)上建复合索引，因当前Filter: status = 'pending' AND created_at > now() - interval '7 days'，单列索引无法覆盖range scan + equality filter组合。”
提供反例Prompt，避免Kimi胡乱猜测
方法一：用否定式约束防止发散
“不分析应用层连接池配置、不讨论JDBC驱动参数、不假设网络延迟、不建议升级硬件——所有结论必须能在pg_stat_statements、pg_locks、pg_stat_progress_vacuum中查到对应指标。”
方法二：设定错误答案拦截机制
“若执行计划中未出现Nested Loop，禁止提及‘减少嵌套循环’；若Buffers中没有Local块，禁止分析temp_file或临时表问题。”
这一步操作起来很简单，直接把上述两段否定指令粘贴在Prompt末尾即可生效。