缓慢的数据库查询会让用户感到沮丧，并增加基础设施成本。该技能提供系统化的模式来分析查询计划、设计有效的索引，并将缓慢的 SQL 转换为高性能操作。
下载技能 ZIP
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
开启并开始使用
测试它
正在使用“sql-optimization-patterns”。 在 1000 万行表上进行顺序扫描的查询
预期结果:
分析：EXPLAIN 显示顺序扫描，因为在 WHERE 子句中使用的 'created_at' 列上不存在索引。建议：CREATE INDEX idx_orders_created ON orders(created_at DESC)。预期改进：对于最近的日期范围，查询时间应从 2.3 秒降至 50 毫秒以下。
正在使用“sql-optimization-patterns”。 N+1 模式单独加载用户订单
预期结果:
问题：执行了 101 个查询（1 个用于用户 + 100 个用于订单）。解决方案：替换单个 JOIN 查询，或使用 WHERE user_id IN (...) 进行批量加载。重构方法将数据库往返减少 99%，总执行时间从 5.2 秒降至 120 毫秒。
安全审计
安全Static analysis flagged 103 potential issues that are all false positives. The 'external_commands' findings are markdown code fence backticks in documentation, not shell execution. The 'weak cryptographic algorithm' findings reference SQL examples, not actual crypto code. The 'filesystem' finding is a PostgreSQL COPY command syntax example in documentation. This skill contains only markdown documentation with SQL optimization patterns and examples - no executable code or security risks.
质量评分
你能构建什么
电商平台优化
开发团队在高峰流量期间遇到产品搜索和订单历史查询缓慢的问题。该技能帮助他们分析慢查询日志，识别频繁过滤列上缺失的索引，并重构订单加载中的 N+1 模式，将 API 响应时间从秒级降低到毫秒级。
分析仪表板性能
数据工程师需要加速实时仪表板的聚合查询，以显示销售指标。该技能指导实施物化视图进行昂贵计算、使用覆盖索引实现仅索引扫描，以及高效的 GROUP BY 模式，从而实现亚秒级的仪表板刷新率。
遗留应用现代化
高级开发人员接手了一个包含数十个慢查询的应用，这些查询导致超时错误。该技能提供系统化的方法：使用 pg_stat_statements 捕获慢查询、分析执行计划、优先考虑高影响的优化，并实施适当的索引以消除 90% 的性能问题，而无需重写应用。
试试这些提示
我有一个慢 SQL 查询，运行时间超过 5 秒。这是查询和表结构：[粘贴查询和架构]。你能分析导致缓慢的原因并建议创建哪些具体索引吗？
我对查询运行了 EXPLAIN ANALYZE，得到以下输出：[粘贴 EXPLAIN 输出]。请解���每个操作的含义，识别性能瓶颈，并推荐具体的优化方法。
我有一个表，包含列 [列出列]，我最常见的查询是：[列出查询]。我应该使用什么索引策略？请考虑复合索引、部分索引和覆盖索引（如适用）。
我的应用程序在循环中执行数百个类似的查询：[描述模式或显示代码]。这导致了性能问题。帮我使用 JOIN、批量加载或其他技术来重构这个问题，以减少数据库往返次数。
最佳实践
- 在优化之前，始终使用 EXPLAIN ANALYZE 来了解实际的查询执行情况
- 在 WHERE、JOIN 和 ORDER BY 子句中使用的列上创建索引——但避免过度索引，因为每个索引都会降低写入操作的速度
- 仅获取所需的列而不是 SELECT *，并尽可能在查询的早期阶段过滤数据
避免
- 在 WHERE 子句中对索引列使用函数而没有相应的函数索引
- 在大表上使用大 OFFSET 值进行分页，而不是基于游标的方法
- 在应用程序循环中执行查询（N+1 模式），而不是批量加载或 JOIN