用途
Database Optimizer 用于解决数据库层面的性能问题，覆盖 PostgreSQL、MySQL、MongoDB 和 Redis 等主流数据库系统。其核心目标是通过查询优化、索引设计、执行计划分析和系统配置调整，实现亚秒级查询性能与最优资源利用率。
主要能力
- 查询优化：分析执行计划并定位瓶颈、重写查询以获得更优性能、优化连接（JOIN）、子查询与聚合操作、实施查询结果缓存策略。
- 索引设计：设计合适的索引类型（B-tree、GIN、BRIN、hash），为多列查询创建复合索引，为特定查询模式实施部分索引，管理索引维护并避免膨胀。
- 数据库配置：针对特定工作负载调优数据库参数，优化内存分配（缓冲池、缓存大小），配置连接池与并发设置，为大型表实施分区策略。
- 性能监控：搭建查询性能监控与告警，分析慢查询日志并识别模式，实施数据库指标采集（EXPLAIN ANALYZE），建立性能基线与容量规划。
使用方式
该技能通过调用方式使用，适合以下情况：慢查询需要优化（EXPLAIN ANALYZE 显示问题）、索引策略需要设计或审查、需要数据库配置调优、需要容量规划或扩展决策。
不适合以下情况：无性能问题的简单 CRUD 操作、不涉及优化重点的模式设计（应使用 database-administrator）、仅涉及应用层缓存（应使用 backend-developer）。
工作流示例：慢查询优化
场景：生产查询耗时 3.2 秒，需降至 100 毫秒以内。
第 1 步：使用 EXPLAIN (ANALYZE, BUFFERS, VERBOSE) 捕获基线。
第 2 步：从执行计划识别问题，例如顺序扫描而非索引扫描、共享读取过高（缓存未命中）、过滤/连接列缺少索引。
第 3 步：创建策略性索引，例如为 users 表创建带 INCLUDE 和 WHERE 子句的覆盖部分索引，为 orders 表的 JOIN 创建覆盖索引，并运行 ANALYZE 更新统计信息。
第 4 步：验证优化，再次运行 EXPLAIN 确认出现 Index Only Scan、Heap Fetches 为 0、执行时间低于 100 毫秒。
预期结果：执行时间降低 95% 以上，缓冲区读取消除，顺序扫描被索引扫描替代，查询计划稳定可预测。
适用场景
查询执行时间超出性能目标（OLTP 超过 100ms，分析型超过 5s）、数据库 CPU/内存/IO 利用率持续高于 70%、应用出现数据库连接耗尽或超时、慢查询日志显示问题模式或缺少索引、数据库难以应对预期负载或流量高峰、复制延迟超过可接受阈值、需要针对特定工作负载优化数据库配置、规划数据库容量或水平扩展策略。
限制
资料未提供具体支持的数据库版本范围、部署环境要求、许可证与收费信息，也未提供安装命令。该技能以工作流指导和最佳实践为主，实际效果取决于目标数据库的具体情况。
性能目标参考
OLTP 场景：P50 延迟 <50ms、P95 <100ms、P99 <200ms、缓存命中率 >95%、索引使用率 >95%。分析型场景：P50 <2s、P95 <5s、P99 <10s、缓存命中率 >90%、索引使用率 >80%。
配置参考
shared_buffers 为内存的 25%，effective_cache_size 为内存的 75%，work_mem 为 内存/最大连接数/4，maintenance_work_mem 为内存的 10%，random_page_cost 在 SSD 下为 1.1、HDD 下为 4.0。
升级提示
查询复杂度爆炸时建议升级给架构师进行模式重设计；复制延迟超过 10s 时建议升级给 DBA 进行基础设施审查；连接池耗尽时应检查应用的连接处理；磁盘 IO 饱和时应考虑只读副本或缓存层。