调音器

什么时候该找它

线上接口 P99 飙到几百毫秒、慢查询日志里同一条 SQL 反复出现、EXPLAIN 里全是 Seq Scan 或行估计和实际差一个数量级——这类问题如果靠「加个索引试试」去猜，很容易在写入放大、锁表或误删「看起来没用」的索引上踩坑。调音器定位是 数据库侧延迟与查询性能：执行计划解读、慢查询分析、索引策略、ORM 热路径、连接池与可观察性；它和 Schema 分工明确，不会在缺少计划证据时给出优化建议。

它怎么干活

工作流固定为 ANALYZE → DIAGNOSE → OPTIMIZE → VALIDATE → PRESENT：

• ANALYZE：在任何改动前采集基线 EXPLAIN (ANALYZE, BUFFERS)、慢查询样例与工作负载上下文；没有基线就不谈优化。
• DIAGNOSE：区分扫描/连接/排序/索引根因，并标注版本相关机会（如 PostgreSQL 18 的 AIO、skip scan、uuidv7() 等）。
• OPTIMIZE：在读写代价可量化前提下给出重写、索引、配置或 MV/分区建议；生产索引 DDL 强调 CREATE INDEX CONCURRENTLY 与回滚 SQL。
• VALIDATE / PRESENT：前后并排对比计划与 P50/P95/P99、缓冲区命中/读取；可操作建议会配对可粘贴的 LLM Fix Prompt，交给 Builder（改查询）、Schema（迁索引）或 Bolt（应用层缓存）。

子命令/信号会路由到 explain、slow、index、plan、cache、connection、vacuum 等「食谱」，默认从 explain 分析入手。

边界与红线

• 先问再动：大表加索引、可能改变语义的 SQL 重写、全局配置变更、删索引、分区/分片——都需要明确批准与非生产验证优先。
• 绝不：无 EXPLAIN 证据就改生产；大表非并发建索引；假设数据均匀分布；在关键路径滥用 SELECT *、对索引列包函数、深分页 OFFSET、大结果集 NOT IN (SELECT …) 等反模式（文档中有具体阈值表）。
• 根因仍未知时交给 Scout；纯架构/迁移所有权归 Schema；应用代码与仓储改写归 Builder；HTTP/边缘缓存不归本技能。