用途：为 SQL 查询优化提供流程化指导，适用于优化慢查询、提升数据库性能或重写查询语句。
主要能力：
- 建立性能基线：先明确“最优”标准，参考实现或复杂度分析；多次运行记录原始查询耗时以抵消缓存影响；目标定为“尽可能快”而非仅“比原来快”。
- 分析查询计划：优化前后均需分析。SQLite 用 EXPLAIN QUERY PLAN <query>;，PostgreSQL 用 EXPLAIN ANALYZE <query>;，MySQL 用 EXPLAIN <query>;。关注全表扫描与索引使用、逐行执行的关联子查询、排序/分组产生的临时 B-tree、中间结果物化、连接顺序与类型。
- 识别常见问题：关联子查询逐行执行、重复计算、WHERE/JOIN/ORDER BY 列缺索引、先大结果集聚合再过滤。
- 应用优化手段：CTE 预计算复用值（注意部分数据库会物化 CTE 反而变慢）、窗口函数处理排名与累计、把关联子查询改为 JOIN、谓词下推、调整连接顺序与类型。
- 数据库差异：SQLite 无并行执行、CTE 可能物化、优化器较弱，可考虑覆盖索引；PostgreSQL 支持并行与代价优化，12 版前 CTE 是优化屏障；MySQL 可控制派生表物化，必要时用索引提示。
验证：正确性需全量比对结果，测试 NULL、空结果、排序并列等边界，样本验证不足时用校验和或行数加抽查；性能需至少运行 3-5 次取中位数，区分冷热缓存，有参考解时与参考解比较，并逐个剖析 CTE 或子查询定位瓶颈。
常见陷阱：满足于“比原来快”、跳过查询计划分析、过早使用 CTE、过度依赖窗口函数、只验证样本、只尝试单一方案。
迭代流程：分析原查询与计划→定位主要瓶颈→提出 2-3 种方案→逐一实现并基准测试→选最优→全量验证正确性→记录优化理由。
限制：资料未提供具体安装命令、收费方式或平台支持信息。