用途：分析并实施 API 调用、数据库查询与数据处理模式上的性能优化，适合定位瓶颈、批量化操作、修复 N+1 查询、并行化独立操作和添加数据库索引。
作用范围：先限定在当前仓库内搜索代码；运行时性能调查先限定在当前仓库的活跃可观测性项目中，仅在明确要求时才扩展到其他项目或仓库。
证据来源：提出深度重构或大范围架构改动前，先用可观测性数据确认真实热点；已由本地性能分析、测试或明显的静态 N+1／串行模式证实的局部小优化，可跳过 Sentry 项目发现。Sentry MCP 作为主要运行时来源，用于在项目发现后检查慢事务、慢 span 和高百分位延迟；运行时行为不确定、怀疑跨服务延迟或考虑深度重构时执行发现流程，优先采用近期窗口和聚合视图的证据。
可选工具：需要基础设施、日志、数据库上下文时加载 agent-tools，例如 bun run logs-tool ... 查看日志时序、bun run db-tool ... 做 SQL 与行数／基数检查、bun run k8s-tool ... 查看 Pod CPU 与内存节流及运行时压力。若当前运行环境没有该技能，可回退到仓库内日志与调试埋点、测试夹具与可复现基准脚本、数据库查询计划与计时输出（如 EXPLAIN (ANALYZE, BUFFERS)），并在无法采集基础设施数据时明确说明不确定性。
分析流程：先识别高影响模式，包括带 API／DB 调用的 N+1 循环、可并行却串行的独立调用、循环内单条插入／更新／删除、可改为 upsert 的反复先读后写。再做优化：用 inArray 与查找映射批量读取；批量写入；在多查询合并能改善基数与延迟时用连接／子查询整合；用 Effect.all、Effect.forEach(..., { concurrency }) 与 Promise.all 并行独立工作；用 upsert 避免先读后写往返。完整代码示例放在 references 中。
索引建议：单列频繁过滤、多列组合过滤、频繁排序的 ORDER BY 列可考虑索引；PostgreSQL 不会自动为外键列建索引，外键列用于连接、过滤或级联删除／更新时应显式创建。
验证与度量：先建立基线，记录目标路径 p50／p95 延迟、查询次数、吞吐以及内存与错误率信号和基线窗口与负载假设；一次只改一类热点，保持功能行为与错误语义；运行 bun run check 和相关测试，确认错误处理、日志与外部 API 并发限制；在可比负载下重新测量，确认改善不是噪声；保留基准或追踪证据，为关键路径补测试，并记录仍需基础设施验证的剩余瓶颈。
限制：资料未提供具体支持的编程语言、框架版本、计费、平台与效果承诺；引用文件为 references/effect-parallel-patterns.md 与 references/drizzle-batch-patterns.md。